Buildroot用户手册

https://buildroot.org/downloads/manual/manual.html
Buildroot用户手册
目录

一，入门
1.关于Buildroot
2.系统要求
2.1。强制性包裹
2.2。可选包
3.获得Buildroot
4. Buildroot快速入门
5.社区资源
II。用户指南
6. Buildroot配置
6.1。交叉编译工具链
6.2。/ dev管理
6.3。init系统
7.配置其他组件
8.一般Buildroot用法
8.1。做提示
8.2。了解何时需要完全重建
8.3。了解如何重建包
8.4。离线构建
8.5。在树外建造
8.6。环境变量
8.7。有效处理文件系统映像
8.8。绘制包之间的依赖关系
8.9。绘制构建持续时间
8.10。绘制包的文件系统大小贡献图
8.11。与Eclipse集成
8.12。高级用法
9.项目特定的定制
9.1。推荐的目录结构
9.2。在Buildroot之外保留自定义
9.3。存储Buildroot配置
9.4。存储其他组件的配置
9.5。自定义生成的目标文件系统
9.6。添加自定义用户帐户
9.7。创建图像后的自定义
9.8。添加项目特定的修补程序
9.9。添加特定于项目的包
9.10。存储项目特定自定义的快速指南
10.常见问题和故障排除
10.1。启动网络后启动挂起…
10.2。为什么目标上没有编译器？
10.3。为什么目标上没有开发文件？
10.4。为什么目标没有文档？
10.5。为什么在Buildroot配置菜单中看不到某些包？
10.6。为什么不将目标目录用作chroot目录？
10.7。为什么Buildroot不生成二进制包（.deb，.ipkg …）？
10.8。如何加快构建过程？
11.已知问题
12.法律声明和许可
12.1。遵守开源许可证
12.2。遵守Buildroot许可证
13.超越Buildroot
13.1。引导生成的图像
13.2。chroot环境
III。开发者指南
14. Buildroot的工作原理
15.编码风格
15.1。Config.in文件
15.2。该.mk文件
15.3。文档
15.4。支持脚本
16.添加对特定板的支持
17.向Buildroot添加新包
17.1。包目录
17.2。配置文件
17.3。该.mk文件
17.4。该.hash文件
17.5。具有特定构建系统的包的基础结构
17.6。基于autotools的软件包的基础结构
17.7。基于CMake的软件包的基础架构
17.8。Python包的基础结构
17.9。基于LuaRocks的软件包的基础结构
17.10。Perl / CPAN包的基础结构
17.11。虚拟包的基础结构
17,12。使用kconfig配置文件的软件包的基础结构
17.13。基于螺纹钢的包的基础设施
17.14。基于Waf的软件包的基础结构
17.15。基于Meson的包的基础结构
17.16。集成基于货物的包裹
17.17。Go包的基础设施
17.18。构建内核模块的包的基础结构
17.19。asciidoc文档的基础结构
17.20。特定于Linux内核包的基础结构
17.21。钩子可用于各种构建步骤
17.22。Gettext集成和与包的交互
17.23。技巧和窍门
17.24。结论
18.修补包裹
18.1。提供补丁
18.2。如何应用补丁
18.3。包修补程序的格式和许可
18.4。集成Web上的补丁
19.下载基础设施
20.调试Buildroot
21.为Buildroot做贡献
21.1。重现，分析和修复错误
21.2。分析和修复autobuild故障
21.3。查看和测试补丁
21.4。处理TODO列表中的项目
21.5。提交补丁
21.6。报告问题/错误或获得帮助
22. DEVELOPERS文件和get-developers
IV。附录
23. Makedev语法文档
24. Makeusers语法文档
25.从较旧的Buildroot版本迁移
25.1。迁移到2016.11
25.2。迁移到2017.08
实例清单

17.1。配置脚本：神圣包
17.2。配置脚本：imagemagick包：
Buildroot 2018.08.1手册生成于2018-10-07 09:33:31 UTC来自git revision 5cb24d72b2

Buildroot手册由Buildroot开发人员编写。它是根据GNU通用公共许可证版本2 获得许可的。有关此许可证的全文，请参阅Buildroot源中的 COPYING文件。

版权所有©2004-2018 Buildroot开发人员

logo.png
第一部分。入门
第1章关于Buildroot
Buildroot是一种使用交叉编译简化和自动化为嵌入式系统构建完整Linux系统的过程的工具。

为了实现这一目标，Buildroot能够为您的目标生成交叉编译工具链，根文件系统，Linux内核映像和引导加载程序。Buildroot可以独立地用于这些选项的任意组合（例如，您可以使用现有的交叉编译工具链，并仅使用Buildroot构建根文件系统）。

Buildroot主要用于使用嵌入式系统的人员。嵌入式系统通常使用的处理器不是每个人习惯使用的常规x86处理器。它们可以是PowerPC处理器，MIPS处理器，ARM处理器等。

Buildroot支持众多处理器及其变体; 它还配备了现成的几种电路板的默认配置。除此之外，许多第三方项目都是基于或开发在Buildroot之上的BSP [1]或SDK [2]。

[1] BSP：董事会支持包

[2] SDK：软件开发工具包

第2章系统要求
Buildroot旨在在Linux系统上运行。

虽然Buildroot本身将构建编译所需的大多数主机软件包，但预计某些标准Linux实用程序已安装在主机系统上。您将在下面找到强制和可选包的概述（请注意，包名称可能因发行版而异）。

2.1。强制性包裹
构建工具：

which
sed
make （版本3.81或更高版本）
binutils
build-essential （仅适用于基于Debian的系统）
gcc （4.4版或更高版本）
g++ （4.4版或更高版本）
bash
patch
gzip
bzip2
perl （版本5.8.7或更高版本）
tar
cpio
python （2.6或更高版本）
unzip
rsync
file（必须在/usr/bin/file）
bc
源提取工具：

wget
2.2。可选包
配置接口依赖项：

对于这些库，您需要同时安装运行时和开发数据，这些数据在许多发行版中是单独打包的。开发包通常具有-dev或-devel后缀。

ncurses5使用menuconfig界面
qt4使用xconfig接口
glib2，gtk2并glade2使用gconfig接口
源提取工具：

在官方的树，大部分包源通过使用检索 wget从FTP，HTTP或HTTPS位置。一些软件包只能通过版本控制系统获得。此外，Buildroot能够通过其他工具下载源，如rsync或scp （有关更多详细信息，请参阅第19章，下载基础结构）。如果使用上述任何方法启用软件包，则需要在主机系统上安装相应的工具：

bazaar
cvs
git
mercurial
rsync
scp
subversion
与Java相关的包，如果需要为目标系统构建Java Classpath：

该javac编译器
该jar工具
文档生成工具：

asciidoc，版本8.6.3或更高版本
w3m
python使用argparse模块（自动出现在2.7+和3.2+）
dblatex （仅限pdf手册）
图生成工具：

graphviz使用graph-depends和 -graph-depends
python-matplotlib使用图形构建
第3章获取Buildroot
Buildroot发布每3个月发布一次，分别是2月，5月，8月和11月。版本号的格式为YYYY.MM，例如2013.02,2014.08。

可以在http://buildroot.org/downloads/上找到发布tar包。

为方便起见，Buildrootsupport/misc/Vagrantfile源代码树中提供了一个Vagrantfile，可以快速设置具有所需依赖关系的虚拟机。

如果要在Linux或Mac Os X上设置隔离的buildroot环境，请将此行粘贴到终端上：

curl -O https://buildroot.org/downloads/Vagrantfile; 流浪汉
如果您使用的是Windows，请将其粘贴到PowerShell中：

（new-object System.Net.WebClient）.DownloadFile（
“https://buildroot.org/downloads/Vagrantfile","Vagrantfile”）;
流浪汉
如果要跟踪开发，可以使用每日快照或克隆Git存储库。有关更多详细信息，请参阅Buildroot网站的 下载页面。

第4章Buildroot快速入门
重要提示：您可以而且应该像普通用户一样构建所有内容。无需root用户即可配置和使用Buildroot。通过以常规用户身份运行所有命令，可以保护系统免受在编译和安装期间表现不佳的程序包的影响。

使用Buildroot的第一步是创建配置。Buildroot有一个很好的配置工具，类似于Linux内核或 BusyBox中的配置工具。

从buildroot目录中运行

$ make menuconfig
对于原始的基于curses的配置器，或者

$ make nconfig
对于新的基于curses的配置器，或者

$ make xconfig
对于基于Qt的配置器，或

$ make gconfig
对于基于GTK的配置器。

所有这些“make”命令都需要构建一个配置实用程序（包括接口），因此您可能需要为配置实用程序使用的相关库安装“development”包。有关更多详细信息，请参阅第2章，系统要求，特别是可选要求 第2.2节“可选包”， 以获取您喜欢的界面的依赖关系。

对于配置工具中的每个菜单条目，您可以找到描述条目用途的相关帮助。 有关某些特定配置方面的详细信息，请参阅第6章，Buildroot配置。

配置完所有内容后，配置工具将生成.config包含整个配置的 文件。该文件将由顶级Makefile读取。

要开始构建过程，只需运行：

$ make
您永远不应该使用make -jNBuildroot：目前不支持顶级并行make。相反，使用该BR2_JLEVEL选项告诉Buildroot运行每个包的编译make -jN。

该make命令通常会执行以下步骤：

下载源文件（根据需要）;
配置，构建和安装交叉编译工具链，或者只是导入外部工具链;
配置，构建和安装选定的目标包;
如果选择，则构建内核映像;
如果选择，则构建引导加载程序映像;
以选定的格式创建根文件系统。
Buildroot输出存储在一个目录中output/。该目录包含几个子目录：

images/其中存储了所有图像（内核映像，引导加载程序和根文件系统映像）。这些是您需要放在目标系统上的文件。
build/构建所有组件的位置（包括主机上Buildroot所需的工具和为目标编译的包）。该目录包含每个组件的一个子目录。
staging/其中包含类似于根文件系统层次结构的层次结构。此目录包含交叉编译工具链的标头和库以及为目标选择的所有用户空间包。但是，此目录不是目标的根文件系统：它包含许多开发文件，未被剥离的二进制文件和库，这使得它对于嵌入式系统来说太大了。这些开发文件用于编译依赖于其他库的目标库和应用程序。
target/它几乎包含了目标的完整根文件系统：除了设备文件之外，所有需要的东西都存在 /dev/（Buildroot无法创建它们，因为Buildroot不以root身份运行，也不想以root身份运行）。此外，它没有正确的权限（例如busybox二进制文件的setuid）。因此，不应在目标上使用此目录 。相反，您应该使用images/目录中内置的一个图像。如果需要提取的根文件系统映像以通过NFS启动，则使用生成的tarball映像images/并以root身份提取它。相比staging/，target/ 仅包含运行所选目标应用程序所需的文件和库：开发文件（标题等）不存在，二进制文件被剥离。
host/ 包含为正确执行Buildroot所需的为主机编译的工具的安装，包括交叉编译工具链。
这些命令make menuconfig|nconfig|gconfig|xconfig和make基本功能可以让您轻松快速地生成符合您需求的图像，并启用您启用的所有功能和应用程序。

有关“make”命令用法的更多详细信息，请参见 第8.1节“ make tips”。

第5章社区资源
与任何开源项目一样，Buildroot有不同的方式在社区和外部共享信息。

如果您正在寻求帮助，想要了解Buildroot或为项目做出贡献，那么每种方式都会让您感兴趣。

邮件列表
Buildroot有一个用于讨论和开发的邮件列表。它是Buildroot用户和开发人员的主要交互方法。

只允许Buildroot邮件列表的订阅者发布到此列表。您可以通过邮件列表信息页面订阅 。

发送到邮件列表的邮件也可以在邮件列表档案中找到，也可以 通过Gmane，at gmane.comp.lib.uclibc.buildroot。请在提问之前搜索邮件列表档案，因为其他人之前很可能会问过同样的问题。

IRC
Buildroot IRC频道#buildroot托管在Freenode上。这是一个有用的地方，可以提出快速问题或讨论某些主题。

在IRC上寻求帮助时，请使用代码共享网站（例如http://code.bulix.org）共享相关日志或代码段。

请注意，对于某些问题，发布到邮件列表可能会更好，因为它会覆盖更多人，包括开发人员和用户。

Bug跟踪器
可以通过邮件列表或者通过Buildroot bugtracker报告Buildroot中的错误。在创建错误报告之前，请参阅第21.6节“报告问题/错误或获取帮助”。
维基
Buildroot wiki页面托管在eLinux wiki上。它包含一些有用的链接，过去和即将发生的事件的概述，以及TODO列表。
拼凑物
Patchwork是一个基于Web的补丁跟踪系统，旨在促进对开源项目的贡献和管理。已发送到邮件列表的修补程序被系统“捕获”，并显示在网页上。发布的任何评论都将参考补丁附加到补丁页面。有关Patchwork的更多信息，请参阅 http://jk.ozlabs.org/projects/patchwork/。

Buildroot的Patchwork网站主要供Buildroot的维护者使用，以确保不会遗漏补丁。它也被Buildroot补丁审阅者使用（另请参见第21.3.1节“从拼凑处应用补丁”）。但是，由于网站在简洁的Web界面中公开补丁及其相应的评论评论，因此对所有Buildroot开发人员都很有用。

Buildroot补丁管理界面可从 http://patchwork.buildroot.org获得。

第二部分。用户指南
第6章Buildroot配置
所有配置选项make *config都有一个帮助文本，提供有关该选项的详细信息。

这些make *config命令还提供了一个搜索工具。阅读不同前端菜单中的帮助信息，了解如何使用它：

在menuconfig中，按下调用搜索工具/;
在xconfig中，按Ctrl+键调用搜索工具f。
搜索结果显示匹配项的帮助消息。在menuconfig中，左列中的数字提供了相应条目的快捷方式。只需输入此数字即可直接跳转到条目，或者输入包含菜单，以防由于缺少依赖项而无法选择条目。

虽然条目的菜单结构和帮助文本应该是不言自明的，但是许多主题需要在帮助文本中不能轻易涵盖的其他说明，因此将在以下各节中介绍。

6.1。交叉编译工具链
编译工具链是一组工具，允许您为系统编译代码。它由一个编译器（在我们的例子中gcc），二进制工具包如汇编器和链接器（在我们的例子中binutils）和一个C标准库（例如 GNU Libc， uClibc-ng）组成。

安装在开发站上的系统当然已经有一个编译工具链，您可以使用它来编译在您的系统上运行的应用程序。如果您使用的是PC，则编译工具链在x86处理器上运行，并为x86处理器生成代码。在大多数Linux系统下，编译工具链使用GNU libc（glibc）作为C标准库。此编译工具链称为“主机编译工具链”。它正在运行的机器以及你正在运行的机器被称为“主机系统” [3]。

编译工具链由您的发行版提供，Buildroot与它无关（除了使用它来构建交叉编译工具链和在开发主机上运行的其他工具）。

如上所述，系统附带的编译工具链运行并为主机系统中的处理器生成代码。由于您的嵌入式系统具有不同的处理器，您需要交叉编译工具链 - 在主机系统上运行但为目标系统（和目标处理器）生成代码的编译工具链。例如，如果主机系统使用x86并且目标系统使用ARM，则主机上的常规编译工具链在x86上运行并生成x86的代码，而交叉编译工具链在x86上运行并为ARM生成代码。

Buildroot为交叉编译工具链提供了两种解决方案：

所述内部工具链后端，称为Buildroot toolchain在配置接口。
的外部工具链后端，称为External toolchain在配置接口。
使用菜单中的Toolchain Type选项可以选择这两种解决方案Toolchain。一旦选择了一个解决方案，就会出现许多配置选项，以下各节将详细介绍它们。

6.1.1。内部工具链后端
该内部工具链后端的后端，其中Buildroot里面建立本身就是一个交叉编译工具链，建设目标嵌入式系统的用户空间应用程序和库前。

这个后端支持几个C库： uClibc-ng， glibc和 musl。

选择此后端后，会出现许多选项。最重要的是允许：

更改用于构建工具链的Linux内核头的版本。这个项目值得一些解释。在构建交叉编译工具链的过程中，正在构建C库。该库提供了用户空间应用程序和Linux内核之间的接口。为了知道如何与Linux内核“交谈”，C库需要访问 Linux内核头文件（即内核中的.h文件），它们定义了用户空间和内核之间的接口（系统调用，数据结构）等）。由于此接口是向后兼容的，因此用于构建工具链的Linux内核头的版本不需要完全匹配您打算在嵌入式系统上运行的Linux内核版本。它们只需要与您打算运行的Linux内核版本相同或更旧的版本。如果您使用的内核头文件比您在嵌入式系统上运行的Linux内核更新，那么C库可能正在使用Linux内核未提供的接口。
更改GCC编译器，binutils和C库的版本。
选择一些工具链选项（仅限uClibc）：工具链是否应具有RPC支持（主要用于NFS），宽字符支持，语言环境支持（用于国际化），C ++支持或线程支持。根据您选择的选项，Buildroot菜单中可见的用户空间应用程序和库的数量将发生变化：许多应用程序和库需要启用某些工具链选项。当需要某个工具链选项来启用这些包时，大多数软件包都会显示注释。如果需要，您可以通过运行进一步优化uClibc配置make uclibc-menuconfig。但请注意，Buildroot中的所有软件包都是针对Buildroot中捆绑的默认uClibc配置进行测试的：如果您通过从uClibc中删除功能而偏离此配置，则某些软件包可能不再构建。
值得注意的是，只要修改了其中一个选项，就必须重建整个工具链和系统。请参见 第8.2节“了解何时需要完全重建”。

这个后端的优点：

与Buildroot完美集成
快速，只构建必要的东西
这个后端的缺点：

这样做需要重建工具链make clean，这需要时间。如果您正在尝试减少构建时间，请考虑使用外部工具链后端。
6.1.2。外部工具链后端
在外部工具链后端允许使用现有的预建交叉编译工具链。Buildroot了解一些众所周知的交叉编译工具链（来自 Linaro for ARM， Sourcery CodeBench for ARM，x86-64，PowerPC和MIPS，并且能够自动下载它们，或者它可以指向自定义工具链，可以下载或本地安装。

然后，您有三个使用外部工具链的解决方案：

使用预定义的外部工具链配置文件，让Buildroot下载，提取并安装工具链。Buildroot已经了解了一些CodeSourcery和Linaro工具链。只需Toolchain从可用的工具链配置文件中选择工具链配置文件。这绝对是最简单的解决方案。
使用预定义的外部工具链配置文件，但您可以告诉Buildroot您的系统上已经安装了工具链，而不是让Buildroot下载并解压缩工具链。只需Toolchain通过可用的工具链配置文件选择工具链配置文件，取消选择Download toolchain automatically，然后在Toolchain path文本条目中填入 交叉编译工具链的路径。
使用完全自定义的外部工具链。这对使用crosstool-NG或Buildroot本身生成的工具链特别有用。为此，请Custom toolchain在Toolchain列表中选择解决方案 。您需要填写的Toolchain path，Toolchain prefix和External toolchain C library选项。然后，您必须告诉Buildroot您的外部工具链支持什么。如果您的外部工具链使用glibc库，您只需要判断您的工具链是否支持C ++以及它是否具有内置的RPC支持。如果您的外部工具链使用uClibc 库，那么你必须告诉Buildroot它是否支持RPC，宽字符，语言环境，程序调用，线程和C ++。在执行开始时，Buildroot将告诉您所选选项是否与工具链配置不匹配。
我们使用CodeSourcery和Linaro的工具链，crosstool-NG生成的工具链以及Buildroot自身生成的工具链测试了我们的外部工具链支持 。通常，支持sysroot功能的所有工具链 都应该有效。如果没有，请不要犹豫与开发人员联系。

我们不支持OpenEmbedded或Yocto生成的工具链或SDK，因为这些工具链不是纯工具链（即只是编译器，binutils，C和C ++库）。相反，这些工具链带有一大堆预编译的库和程序。因此，Buildroot无法导入工具链的sysroot，因为它将包含数百兆字节的预编译库，这些库通常由Buildroot构建。

我们也不支持使用分发工具链（即您的发行版安装的gcc / binutils / C库）作为为目标构建软件的工具链。这是因为您的分发工具链不是“纯”工具链（即仅与C / C ++库一起使用），因此我们无法将其正确导入Buildroot构建环境。因此，即使您要为x86或x86_64目标构建系统，也必须使用Buildroot或crosstool-NG生成交叉编译工具链。

如果你想为你的项目生成一个自定义工具链，可以在Buildroot中用作外部工具链，我们的建议绝对是用crosstool-NG构建它。我们建议从Buildroot单独构建工具链，然后 使用外部工具链后端在Buildroot中导入它。

这个后端的优点：

允许使用众所周知且经过良好测试的交叉编译工具链。
避免交叉编译工具链的构建时间，这在嵌入式Linux系统的整体构建时间中通常非常重要。
这个后端的缺点：

如果您预先构建的外部工具链有错误，可能很难从工具链供应商处获得修复，除非您使用Crosstool-NG自己构建外部工具链。
外部工具链包装
使用外部工具链时，Buildroot会生成一个包装程序，该程序透明地将适当的选项（根据配置）传递给外部工具链程序。如果您需要调试此包装器以准确检查传递的参数，可以将环境变量设置BR2_DEBUG_WRAPPER为以下任一项：

0，空或未设置：无调试
1：在一行上跟踪所有参数
2：每行跟踪一个参数
6.2。/ dev管理
在Linux系统上，该/dev目录包含称为设备文件的特殊文件， 允许用户空间应用程序访问由Linux内核管理的硬件设备。如果没有这些设备文件，您的用户空间应用程序将无法使用硬件设备，即使Linux内核正确识别它们也是如此。

在System configuration，在，/dev managementBuildroot提供了四种不同的解决方案来处理/dev目录：

第一个解决方案是静态使用设备表。这是在Linux中处理设备文件的古老经典方式。使用此方法，设备文件将持久存储在根文件系统中（即它们会在重新启动后保持不变），并且在从系统添加或删除硬件设备时，没有任何内容可以自动创建和删除这些设备文件。因此，Buildroot使用设备表创建一组标准设备文件，默认设置存储在system/device_table_dev.txtBuildroot源代码中。当Buildroot生成最终的根文件系统映像时，将处理此文件， 因此设备文件在output/target目录中不可见。该 BR2_ROOTFS_STATIC_DEVICE_TABLE选项允许更改Buildroot使用的默认设备表，或添加其他设备表，以便在构建期间由Buildroot创建其他设备文件。因此，如果您使用此方法，并且 系统中缺少设备文件，则可以创建一个board///device_table_dev.txt包含其他设备文件描述的文件，然后您可以设置BR2_ROOTFS_STATIC_DEVICE_TABLE为 system/device_table_dev.txt board///device_table_dev.txt。有关设备表文件格式的更多详细信息，请参见 第23章Makedev语法文档。
第二个解决方案是仅使用devtmpfs动态。devtmpfs是Linux内核中的一个虚拟文件系统，已在内核2.6.32中引入（如果使用较旧的内核，则无法使用此选项）。安装后/dev，当系统中添加和删除硬件设备时，此虚拟文件系统将自动使设备文件显示和消失。此文件系统在重新引导后不会持久化：它由内核动态填充。使用devtmpfs需要启用以下内核配置选项： CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT。当Buildroot负责为您的嵌入式设备构建Linux内核时，它会确保启用这两个选项。但是，如果您在Buildroot之外构建Linux内核，那么您有责任启用这两个选项（如果您不这样做，您的Buildroot系统将无法启动）。
第三个解决方案是使用devtmpfs + mdev动态。此方法还依赖于上面详述的devtmpfs虚拟文件系统（因此在内核配置中具有CONFIG_DEVTMPFS和 CONFIG_DEVTMPFS_MOUNT启用的要求仍然适用），但在其mdev上添加了用户空间实用程序。mdev 是BusyBox的一个程序部分，每次添加或删除设备时内核都会调用它。由于/etc/mdev.conf 配置文件，mdev可以配置为例如设置设备文件的特定权限或所有权，每当设备出现或消失时调用脚本或应用程序等。基本上，它允许用户空间对设备添加和删除事件做出反应。mdev例如，当设备出现在系统上时，可以用于自动加载内核模块。mdev如果您的设备需要固件，这也很重要，因为它将负责将固件内容推送到内核。mdev是一个轻量级的实现（具有较少的功能）udev。有关mdev其配置文件及其语法的更多详细信息，请参阅 http://git.busybox.net/busybox/tree/docs/mdev.txt。
第四个解决方案是使用devtmpfs + eudev动态。此方法还依赖于上面详述的devtmpfs虚拟文件系统，但在其eudev上添加了用户空间守护程序。eudev 是一个在后台运行的守护进程，当从系统添加或删除设备时，内核将调用该守护进程。它是一个比重量级更重要的解决方案mdev，但提供更高的灵活性。 eudev是udev大多数桌面Linux发行版中使用的原始用户空间守护程序的独立版本，现在是Systemd的一部分。有关更多详细信息，请参阅 http://en.wikipedia.org/wiki/Udev。
Buildroot开发人员的建议是从Dynamic使用devtmpfs only解决方案开始，直到你需要在添加/删除设备时通知用户空间，或者需要固件时，在这种情况下使用devtmpfs + mdev动态通常是好的解。

请注意，如果systemd选择作为init系统，则/ dev管理将由udev提供的程序执行systemd。

6.3。init系统
该INIT程序是由内核（它携带PID号1）开始的第一用户空间程序，并且是负责启动用户空间服务和程序（例如：网络服务器，图形应用程序，其他网络服务器等）。

的buildroot允许使用三种不同类型的初始化系统，它可以从被选择的System configuration，Init system：

第一个解决方案是BusyBox。在许多程序中，BusyBox具有基本init程序的实现，这对于大多数嵌入式系统来说已经足够了。启用BR2_INIT_BUSYBOX将确保BusyBox将构建和安装其init程序。这是Buildroot中的默认解决方案。BusyBox init程序将/etc/inittab在启动时读取文件以了解要执行的操作。该文件的语法可以在http://git.busybox.net/busybox/tree/examples/inittab中找到 （请注意，BusyBox inittab语法很特殊：不要使用inittab Internet上的随机文档来了解BusyBox inittab）。inittabBuildroot中的默认值存储在 system/skeleton/etc/inittab。除了安装一些重要的文件系统之外，默认inittab所做的主要工作是启动 /etc/init.d/rcSshell脚本，并启动一个getty程序（提供登录提示）。
第二个解决方案是systemV。该解决方案使用旧的传统sysvinit程序，打包在Buildroot中 package/sysvinit。这是大多数桌面Linux发行版中使用的解决方案，直到他们切换到更新的替代品，如Upstart或Systemd。sysvinit也适用于inittab文件（其语法与BusyBox略有不同）。inittab使用此init解决方案安装的默认值位于package/sysvinit/inittab。
第三种解决方案是systemd。systemd是Linux的新一代init系统。它远远超过传统的init 程序：积极的并行化功能，使用套接字和D-Bus激活来启动服务，提供按需启动守护进程，使用Linux控制组跟踪进程，支持快照和恢复系统状态，等等systemd对于相对复杂的嵌入式系统是有用的，例如需要D-Bus和彼此之间通信的服务。值得一提的是，systemd 带来了大量的依赖性相当大的数字：dbus，udev 等等。有关详细信息systemd，请参阅 http://www.freedesktop.org/wiki/Software/systemd。
Buildroot开发人员推荐的解决方案是使用 BusyBox init，因为它足以满足大多数嵌入式系统的要求。systemd可用于更复杂的情况。

[3]这个术语与GNU configure使用的术语不同，其中主机是运行应用程序的机器（通常与目标相同）

第7章其他组件的配置
在尝试修改下面的任何组件之前，请确保您已经自己配置了Buildroot，并启用了相应的软件包。

BusyBox的
如果您已有BusyBox配置文件，则可以使用在Buildroot配置中直接指定此文件 BR2_PACKAGE_BUSYBOX_CONFIG。否则，Buildroot将从默认的BusyBox配置文件开始。

要对配置进行后续更改，请使用make busybox-menuconfig打开BusyBox配置编辑器。

也可以通过环境变量指定BusyBox配置文件，但不建议这样做。有关更多详细信息，请参见 第8.6节“环境变量”。

uClibc的
uClibc的配置方式与BusyBox相同。用于指定现有配置文件的配置变量是 BR2_UCLIBC_CONFIG。进行后续更改的命令是make uclibc-menuconfig。
Linux内核
如果您已有内核配置文件，则可以使用在Buildroot配置中直接指定此文件 BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG。

如果您还没有内核配置文件，则可以首先在Buildroot配置中指定defconfig，使用 BR2_LINUX_KERNEL_USE_DEFCONFIG，或者首先创建一个空文件并将其指定为自定义配置文件 BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG。

要对配置进行后续更改，请使用make linux-menuconfig打开Linux配置编辑器。

Barebox
Barebox的配置方式与Linux内核相同。相应的配置变量是 BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG和 BR2_TARGET_BAREBOX_USE_DEFCONFIG。要打开配置编辑器，请使用make barebox-menuconfig。
的U-Boot
U-Boot（版本2015.04或更新版本）的配置与Linux内核的配置相同。相应的配置变量是BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG和 BR2_TARGET_UBOOT_USE_DEFCONFIG。要打开配置编辑器，请使用make uboot-menuconfig。
第8章常规Buildroot用法
8.1。 做提示
这是一系列提示，可帮助您充分利用Buildroot。

显示make执行的所有命令：

$ make V = 1
显示带defconfig的板列表：

$ make list-defconfigs
显示所有可用目标：

$ make help
并非所有目标始终可用，.config文件中的某些设置可能会隐藏某些目标：

busybox-menuconfig仅在busybox启用时有效;
linux-menuconfig并且linux-savedefconfig仅在linux启用时工作 ;
uclibc-menuconfig 只有在内部工具链后端选择了uCl​​ibc C库时才可用;
barebox-menuconfig并且barebox-savedefconfig仅在barebox启用引导加载程序时有效 。
uboot-menuconfig并且uboot-savedefconfig仅在U-Boot启用引导加载程序时有效 。
清理： 更改任何体系结构或工具链配置选项时，需要进行明确清除。

要删除所有构建产品（包括构建目录，主机，登台和目标树，图像和工具链）：

$ make clean
生成手册： 本手册源位于docs / manual目录中。要生成手册：

$ make手动清洁
$ make manual
手动输出将在output / docs / manual中生成。

笔记

构建文档需要一些工具（参见： 第2.2节“可选包”）。
为新目标重置Buildroot： 删除所有构建产品以及配置：

$ make distclean
笔记。 如果ccache已启用，则运行make clean或distclean不清空Buildroot使用的编译器缓存。要删除它，请参见第8.12.3节“ ccache在Buildroot中使用”。

转储内部make变量： 可以转储已知的所有变量及其值：

$ make -s printvars
变量= value_of_variable
…
可以使用一些变量调整输出：

VARS 将列表限制为与指定的make-pattern匹配的变量
QUOTED_VARS，如果设置为YES，将单引号
RAW_VARS，如果设置为YES，将打印未展开的值
例如：

$ make -s printvars VARS = BUSYBOX_％DEPENDENCIES
BUSYBOX_DEPENDENCIES =骨架工具链
BUSYBOX_FINAL_ALL_DEPENDENCIES =骨架工具链
BUSYBOX_FINAL_DEPENDENCIES =骨架工具链
BUSYBOX_FINAL_PATCH_DEPENDENCIES =
BUSYBOX_RDEPENDENCIES = ncurses util-linux
$ make -s printvars VARS = BUSYBOX_％DEPENDENCIES QUOTED_VARS = YES
BUSYBOX_DEPENDENCIES =‘骨架工具链’
BUSYBOX_FINAL_ALL_DEPENDENCIES =‘骨架工具链’
BUSYBOX_FINAL_DEPENDENCIES =‘骨架工具链’
BUSYBOX_FINAL_PATCH_DEPENDENCIES = ‘’
BUSYBOX_RDEPENDENCIES =‘ncurses util-linux’
$ make -s printvars VARS = BUSYBOX_％DEPENDENCIES RAW_VARS = YES
BUSYBOX_DEPENDENCIES =骨架工具链
BUSYBOX_FINAL_ALL_DEPENDENCIES = $（排序$（BUSYBOX_FINAL_DEPENDENCIES）$（BUSYBOX_FINAL_PATCH_DEPENDENCIES））
BUSYBOX_FINAL_DEPENDENCIES = $（排序$（BUSYBOX_DEPENDENCIES））
BUSYBOX_FINAL_PATCH_DEPENDENCIES = $（排序$（BUSYBOX_PATCH_DEPENDENCIES））
BUSYBOX_RDEPENDENCIES = ncurses util-linux
引用变量的输出可以在shell脚本中重用，例如：

$ eval $（make -s printvars VARS = BUSYBOX_DEPENDENCIES QUOTED_VARS = YES）
$ echo $ BUSYBOX_DEPENDENCIES
骨架工具链
8.2。了解何时需要完全重建
Buildroot里面不尝试检测一下系统的部分应该在系统配置是通过改变重建make menuconfig，make xconfig或的其他配置工具之一。在某些情况下，Buildroot应该重建整个系统，在某些情况下，只应重建特定的包子集。但是以完全可靠的方式检测这一点非常困难，因此Buildroot开发人员决定不尝试这样做。

相反，用户有责任知道何时需要完全重建。作为提示，这里有一些经验法则可以帮助您了解如何使用Buildroot：

更改目标体系结构配置后，需要进行完整的重建。例如，更改体系结构变体，二进制格式或浮点策略会对整个系统产生影响。
更改工具链配置时，通常需要完全重建。更改工具链配置通常涉及更改编译器版本，C库类型或其配置或其他一些基本配置项，这些更改会对整个系统产生影响。
将其他包添加到配置时，不一定需要完全重建。Buildroot将检测到此包从未构建过，并将构建它。但是，如果此包是可以选择由已构建的包使用的库，则Buildroot不会自动重建这些包。您是否知道应该重建哪些软件包，并且可以手动重建它们，或者您应该进行完全重建。例如，假设您已经使用ctorrent 包构建了一个系统，但没有openssl。您的系统工作正常，但您意识到您希望获得SSL支持ctorrent，因此您openssl在Buildroot配置中启用该 程序包并重新启动构建。Buildroot将检测到这一点openssl应该构建并构建它，但它不会检测ctorrent应该重建以从中openssl添加OpenSSL支持。您将要么必须进行完全重建，要么重建ctorrent自己。
从配置中删除包时，Buildroot不会执行任何特殊操作。它不会从目标根文件系统或工具链sysroot中删除此程序包安装的文件 。需要完全重建才能摆脱这个包。但是，通常您不一定需要立即删除此程序包：您可以等待下一个午休时间从头开始重新构建。
更改包的子选项时，不会自动重建包。进行此类更改后，仅重建此包通常就足够了，除非启用package子选项会向包中添加一些对已经构建的另一个包有用的功能。同样，Buildroot不会跟踪何时应该重建包：一旦构建了包，除非明确告知这样做，否则永远不会重建它。
当对根文件系统框架进行更改时，需要完全重建。但是，当对根文件系统覆盖，后构建脚本或后映像脚本进行make更改时，不需要完全重建：简单的调用将考虑更改。
一般来说，当您遇到构建错误并且您不确定所做的配置更改的潜在后果时，请执行完全重建。如果你得到相同的构建错误，那么你确定错误与包的部分重建无关，如果使用官方Buildroot的包发生此错误，请不要犹豫，报告问题！随着您对Buildroot的体验的进步，您将逐步了解何时真正需要完全重建，并且您将节省越来越多的时间。

作为参考，通过运行完成重建：

$ make clean all
8.3。了解如何重建包
Buildroot用户提出的最常见问题之一是如何重建给定的包或如何删除包而无需从头开始重建所有内容。

Buildroot不支持删除程序包，无需从头开始重建。这是因为Buildroot没有跟踪哪个包安装output/staging和 output/target目录中的文件，或者哪个包将根据另一个包的可用性进行不同的编译。

从头开始重建单个包的最简单方法是删除其中的构建目录output/build。然后，Buildroot将从头开始重新提取，重新配置，重新编译和重新安装此软件包。您可以通过make -dirclean命令要求buildroot执行此操作。

另一方面，如果您只想从编译步骤重新启动包的构建过程，则可以运行make -rebuild，然后运行make或make 。它将重新启动程序包的编译和安装，但不是从头开始：它基本上重新执行make并make install 在程序包内部，因此它只会重建已更改的文件。

如果要从配置步骤重新启动程序包的构建过程，可以运行make -reconfigure，然后运行make或make 。它将重新启动程序包的配置，编译和安装。

在内部，Buildroot创建所谓的戳记文件，以跟踪每个包已完成的构建步骤。它们存储在包构建目录中， output/build/-/并且已命名 .stamp_。上面详述的命令只是操纵这些戳记文件，以强制Buildroot重新启动包构建过程的一组特定步骤。

有关包特殊制作目标的更多详细信息，请参见第8.12.5节“特定于 包的制作目标”。

8.4。离线构建
如果您打算进行脱机构建，只想下载先前在配置程序中选择的所有源（menuconfig，nconfig，xconfig或gconfig），则发出：

$ make source
您现在可以断开或将dl 目录的内容复制到构建主机。

8.5。在树外建造
默认情况下，Buildroot构建的所有内容都存储在outputBuildroot树的目录 中。

Buildroot还支持使用类似于Linux内核的语法构建树。要使用它，请添加O=到make命令行：

$ make O = / tmp / build
要么：

$ cd / tmp / build; make O = $ PWD -C path / to / buildroot
所有输出文件都位于/tmp/build。如果O 路径不存在，Buildroot将创建它。

注：该O路径可以是绝对或相对路径，但如果它是一个相对路径通过，需要注意的是它解释为相对于主Buildroot里面源目录，是重要的不是当前的工作目录。

使用树外构建时，Buildroot .config和临时文件也存储在输出目录中。这意味着只要使用唯一的输出目录，就可以使用相同的源树安全地并行运行多个构建。

为了方便使用，Buildroot里面产生的输出目录一个Makefile包装-所以第一次运行之后，就不再需要通过O=<…> 和-C <…>，简单地运行（输出目录）：

$ make
8.6。环境变量
当Buildroot传递给make环境或在环境中设置时，它们也会尊重一些环境变量：

HOSTCXX，主机C ++编译器使用
HOSTCC，主机C编译器使用
UCLIBC_CONFIG_FILE=，uClibc配置文件的路径，用于编译uClibc，如果正在构建内部工具链。注意，uClibc配置文件也可以从配置界面设置，所以通过Buildroot .config文件; 这是设置它的推荐方法。
BUSYBOX_CONFIG_FILE=，BusyBox配置文件的路径。注意，BusyBox配置文件也可以从配置界面设置，所以通过Buildroot .config文件; 这是设置它的推荐方法。
BR2_CCACHE_DIR 在使用ccache时覆盖Buildroot存储缓存文件的目录。
BR2_DL_DIR覆盖Buildroot存储/检索下载文件的目录请注意，也可以从配置界面设置Buildroot下载目录，因此通过Buildroot .config文件。有关如何设置下载目录的更多详细信息，请参见 第8.12.4节“下载的软件包的位置”。
BR2_GRAPH_ALT，如果设置且非空，则在构建时图中使用备用颜色方案
BR2_GRAPH_OUT设置生成的图形的文件类型pdf（默认值）或png。
BR2_GRAPH_DEPS_OPTS将额外选项传递给依赖图; 有关可接受的选项 ，请参见 第8.8节“绘制包之间的依赖关系”
BR2_GRAPH_DOT_OPTS逐字传递作为dot实用程序的选项以绘制依赖关系图。
使用位于顶层目录和$ HOME中的配置文件的示例：

$ make UCLIBC_CONFIG_FILE = uClibc.config BUSYBOX_CONFIG_FILE = $ HOME / bb.config
如果您想使用默认编译器gcc 或g++ 以外的编译器在主机上构建帮助程序二进制文件，那么请执行此操作

$ make HOSTCXX = g ++ - 4.3-HEAD HOSTCC = gcc-4.3-HEAD
8.7。有效处理文件系统映像
文件系统映像可能会变得非常大，具体取决于您选择的文件系统，包的数量，是否配置了可用空间…但是，文件系统映像中的某些位置可能只是空的（例如，一长串 零）; 这样的文件称为稀疏文件。

大多数工具可以有效地处理稀疏文件，并且只存储或写入非空的稀疏文件的那些部分。

例如：

tar接受-S选项告诉它只存储非零的稀疏文件块：

tar cf archive.tar -S [files…] 将有效地存储tarball中的稀疏文件
tar xf archive.tar -S 将有效地存储从tarball中提取的稀疏文件
cp接受该–sparse=WHEN选项（WHEN是一个auto， never或always）：

cp --sparse=always source.file dest.filedest.file如果source.file有很长的零运行， 将生成一个稀疏文件
其他工具可能有类似的选择。请查阅各自的手册页。

如果需要存储文件系统映像（例如从一台机器传输到另一台机器），或者如果需要发送它们（例如，问答团队），则可以使用稀疏文件。

但请注意，在使用稀疏模式时将文件系统映像闪存到设备dd可能会导致文件系统损坏（例如，ext2文件系统的块位图可能已损坏;或者，如果文件系统中有稀疏文件，则这些部分可能不会读回时全为零）。在构建计算机上处​​理文件时，应该只使用稀疏文件，而不是在将它们传输到将在目标上使用的实际设备时使用。

8.8。绘制包之间的依赖关系
Buildroot的工作之一是了解包之间的依赖关系，并确保它们以正确的顺序构建。这些依赖关系有时可能非常复杂，对于给定的系统，通常不容易理解为什么这样或这样的包被Buildroot引入构建。

为了帮助理解依赖关系，从而更好地理解嵌入式Linux系统中不同组件的作用，Buildroot能够生成依赖关系图。

要生成已编译的完整系统的依赖关系图，只需运行：

使图形取决于
您将在中找到生成的图形 output/graphs/graph-depends.pdf。

如果您的系统非常大，则依赖关系图可能过于复杂且难以阅读。因此，可以为给定的包生成依赖图：

make -graph-depends
您将在中找到生成的图形 output/graph/-graph-depends.pdf。

请注意，依赖关系图是使用Graphviz项目中的dot工具生成的，您必须在系统上安装该工具才能使用此功能。在大多数发行版中，它都作为包提供。graphviz

默认情况下，依赖关系图以PDF格式生成。但是，通过传递BR2_GRAPH_OUT环境变量，您可以切换到其他输出格式，例如PNG，PostScript或SVG。支持-T该dot工具选项支持的所有格式。

BR2_GRAPH_OUT = svg make graph-depends
该graph-depends行为可以通过设置选项来控制 BR2_GRAPH_DEPS_OPTS环境变量。接受的选项是：

–depth N, -d N将依赖深度限制为N级别。默认值，0表示没有限制。
–stop-on PKG，-s PKG，停止包装上的图形PKG。 PKG可以是实际的包名称，glob，关键字virtual （在虚拟包上停止）或关键字host（在主机包上停止）。该包仍然存在于图形中，但其依赖性不存在。
–exclude PKG，-x PKG比如–stop-on，但也PKG从图中省略。
–transitive, --no-transitive绘制（或不绘制）传递依赖。默认设置是不绘制传递依赖项。
–colors R,T,H，用逗号分隔的颜色列表来绘制根包（R），目标包（T）和主机包（H）。默认为：lightblue,grey,gainsboro
BR2_GRAPH_DEPS_OPTS =’ - d 3 - 不可传递 - 颜色=红色，绿色，蓝色’使图形依赖
8.9。绘制构建持续时间
当系统的构建需要很长时间时，有时可以了解哪些包构建最长，以查看是否可以采取任何措施来加速构建。为了帮助进行这样的构建时间分析，Buildroot会收集每个包的每个步骤的构建时间，并允许从这些数据生成图形。

要在构建后生成构建时间图，请运行：

制作图形构建
这将生成一组文件output/graphs：

build.hist-build.pdf，每个包的构建时间的直方图，按构建顺序排序。
build.hist-duration.pdf，每个包的构建时间的直方图，按持续时间排序（最长的第一个）
build.hist-name.pdf，每个包的构建时间的直方图，按包名称排序。
build.pie-packages.pdf，每个包的构建时间的饼图
build.pie-steps.pdf，一个饼图，列出了在包构建过程的每个步骤中花费的全局时间。
此graph-build目标需要安装Python Matplotlib和Numpy库（python-matplotlib以及python-numpy大多数发行版），argparse如果您使用的是早于2.7的Python版本（python-argparse在大多数发行版上），还需要安装模块。

默认情况下，图形的输出格式为PDF，但可以使用BR2_GRAPH_OUT环境变量选择不同的格式。支持的唯一其他格式是PNG：

BR2_GRAPH_OUT = png make graph-build
8.10。绘制包的文件系统大小贡献图
当目标系统增长时，了解每个Buildroot包对整个根文件系统大小的贡献有时很有用。为了帮助进行此类分析，Buildroot收集有关每个软件包安装的文件的数据，并使用此数据生成图表和CSV文件，详细说明不同软件包的大小贡献。

要在构建后生成这些数据，请运行：

制作图表大小
这将产生：

output/graphs/graph-size.pdf，每个包对总体根文件系统大小的贡献的饼图
output/graphs/package-size-stats.csv，CSV文件，将每个包的大小贡献分配给整个根文件系统大小
output/graphs/file-size-stats.csv，一个CSV文件，它将每个已安装文件的大小贡献分配给它所属的包，以及整个文件系统大小。
此graph-size目标需要安装Python Matplotlib库（python-matplotlib在大多数发行版上），argparse如果您使用的是早于2.7的Python版本（python-argparse在大多数发行版上），还 需要安装模块。

就像持续时间图一样，BR2_GRAPH_OUT支持一个环境来调整输出文件格式。 有关此环境变量的详细信息，请参见第8.8节“绘制包之间的依赖关系”。

注意。 收集的文件系统大小数据仅在完成干净重建后才有意义。务必make clean all在使用前运行make graph-size。

要比较两个不同Buildroot编译的根文件系统大小，例如在调整配置或切换到另一个Buildroot版本之后，请使用该size-stats-compare脚本。它需要两个 file-size-stats.csv文件（由…生成make graph-size）作为输入。有关更多详细信息，请参阅此脚本的帮助文本：

utils / size-stats-compare -h
8.11。与Eclipse集成
虽然嵌入式Linux开发人员的一部分，如Vim或Emacs等经典文本编辑器，以及基于命令行的界面，但许多其他嵌入式Linux开发人员（如更丰富的图形界面）可以进行开发工作。Eclipse是最受欢迎的集成开发环境之一，Buildroot与Eclipse集成，以简化Eclipse用户的开发工作。

我们与Eclipse的集成简化了构建在Buildroot系统之上的应用程序和库的编译，远程执行和远程调试。它没有将Buildroot配置和构建过程本身与Eclipse集成在一起。因此，Eclipse集成的典型使用模型是：

配置您的Buildroot里面系统make menuconfig，make xconfig或提供Buildroot里面任何其他配置界面。
通过运行构建您的Buildroot系统make。
启动Eclipse以开发，执行和调试您自己的自定义应用程序和库，这将依赖于Buildroot构建和安装的库。
有关Buildroot Eclipse集成安装过程和用法，请参阅 https://github.com/mbats/eclipse-buildroot-bundle/wiki。

8.12。高级用法
8.12.1。使用Buildroot外部生成的工具链
您可能希望为您的目标编译您自己的程序或未在Buildroot中打包的其他软件。为此，您可以使用Buildroot生成的工具链。

Buildroot生成的工具链默认位于 output/host/。使用它的最简单方法是添加 output/host/bin/到您的PATH环境变量，然后使用ARCH-linux-gcc，ARCH-linux-objdump，ARCH-linux-ld，等。

可以重新定位工具链，这允许将工具链分发给其他开发人员以为目标构建应用程序。为达到这个：

run make sdk，准备工具链可重定位;
tarball output/host目录的内容;
分发生成的tarball。
将工具链安装到新位置后，用户必须运行该relocate-sdk.sh脚本以确保使用新位置更新所有路径。

8.12.2。gdb在Buildroot中使用
Buildroot允许进行交叉调试，调试器在构建机器上运行，并与gdbserver目标通信以控制程序的执行。

为达到这个：

如果您使用的是内部工具链（由Buildroot构建），则必须启用BR2_PACKAGE_HOST_GDB，BR2_PACKAGE_GDB和 BR2_PACKAGE_GDB_SERVER。这可确保构建交叉gdb和gdbserver，并将gdbserver安装到目标。
如果您使用的是外部工具链，则应启用 BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY，这会将外部工具链中包含的gdbserver复制到目标。如果您的外部工具链没有交叉gdb或gdbserver，则还可以通过启用与内部工具链后端相同的选项来让Buildroot构建它们。
现在，要开始调试一个名为的程序foo，你应该在目标上运行：

gdbserver：2345 foo
这将导致gdbserver在TCP端口2345上侦听来自交叉gdb的连接。

然后，在主机上，您应该使用以下命令行启动交叉gdb：

/ output / host / bin / -gdb -x / output / staging / usr / share / buildroot / gdbinit foo
当然，foo必须在当前目录中可用，用调试符号构建。通常，您从foo构建的目录中启动此命令（而不是从output/target/该目录中的二进制文件被剥离）。

该/output/staging/usr/share/buildroot/gdbinit文件将告诉交叉gdb在哪里找到目标库。

最后，从cross gdb连接到目标：

（gdb）目标远程<目标IP地址>：2345
8.12.3。ccache在Buildroot中使用
ccache是一个编译器缓存。它存储每个编译过程产生的目标文件，并且能够通过使用预先存在的目标文件来跳过将来编译相同源文件（具有相同的编译器和相同的参数）。从头开始做几乎相同的构建很多次，它可以很好地加快构建过程。

ccache支持集成在Buildroot中。你只需要能够 Enable compiler cache在Build options。这将自动构建ccache并用于每个主机和目标编译。

缓存位于$HOME/.buildroot-ccache。它存储在Buildroot输出目录之外，以便可以由单独的Buildroot构建共享。如果要删除缓存，只需删除此目录即可。

您可以通过运行获取缓存（其大小，命中数，未命中数等）的统计信息make ccache-stats。

make目标ccache-options和CCACHE_OPTIONS变量提供对ccache的更通用访问。例如

#set cache cache limit
使CCACHE_OPTIONS =“ - max-size = 5G”ccache-options

#num statistics counter
使CCACHE_OPTIONS =“ - zero-stats”ccache-options
ccache生成源文件和编译器选项的哈希值。如果编译器选项不同，则不会使用缓存的对象文件。但是，许多编译器选项包含登台目录的绝对路径。因此，在不同的输出目录中构建会导致许多缓存未命中。

为了避免这个问题，buildroot有Use relative paths选项（BR2_CCACHE_USE_BASEDIR）。这将重写所有指向输出目录内的绝对路径到相对路径。因此，更改输出目录不再导致缓存未命中。

相对路径的缺点是它们最终也是目标文件中的相对路径。因此，例如，调试器将不再找到该文件，除非您先cd到输出目录。

有关此重写绝对路径的更多详细信息，请参阅ccache手册的“在不同目录中编译”一节。

8.12.4。下载包的位置
Buildroot下载的各种tarball都存储在BR2_DL_DIR其中，默认情况下是dl目录。如果您想保留已知使用相关tar包的Buildroot的完整版本，则可以复制此目录。这将允许您使用完全相同的版本重新生成工具链和目标文件系统。

如果您维护多个Buildroot树，那么拥有共享下载位置可能会更好。这可以通过将BR2_DL_DIR环境变量指向目录来实现 。如果设置了此项，则会BR2_DL_DIR覆盖Buildroot配置中的值。应添加以下行<~/.bashrc>。

export BR2_DL_DIR = <共享下载位置>
也可以.config使用BR2_DL_DIR选项在文件中 设置下载位置。与.config文件中的大多数选项不同，BR2_DL_DIR环境变量会覆盖此值。

8.12.5。特定于包的制作目标
运行make 构建并安装特定包及其依赖项。

对于依赖于Buildroot基础结构的软件包，有许多特殊的make目标可以像这样独立调用：

make -
包构建目标是（按它们执行的顺序）：

命令/目标 描述
source

获取源代码（下载tarball，克隆源代码库等）

depends

构建并安装构建程序包所需的所有依赖项

extract

将源放在包构建目录中（提取tarball，复制源等）

patch

如果有的话，应用补丁

configure

运行configure命令（如果有）

build

运行编译命令

install-staging

目标包：如有必要，在暂存目录中运行包的安装

install-target

目标包：如有必要，在目标目录中运行包的安装

install

目标包：运行以前的2个安装命令

host包：在主机目录中运行包的安装

此外，还有一些其他有用的制作目标：

命令/目标 描述
show-depends

显示构建程序包所需的依赖项

graph-depends

在当前Buildroot配置的上下文中生成包的依赖关系图。有关依赖关系图的更多详细信息，请参见 本节 第8.8节“绘制包之间的依赖关系”。

dirclean

删除整个包构建目录

reinstall

重新运行安装命令

rebuild

重新运行编译命令 - 这仅在使用该OVERRIDE_SRCDIR功能或直接在构建目录中修改文件时才有意义

reconfigure

重新运行configure命令，然后重建 - 这只在使用该OVERRIDE_SRCDIR功能或直接在构建目录中修改文件时才有意义

8.12.6。在开发期间使用Buildroot
Buildroot的正常操作是下载tarball，解压缩，配置，编译和安装此tarball中的软件组件。源代码被提取出来 output/build/-，这是一个临时目录：无论何时make clean使用，该目录都被完全删除，并在下次make调用时重新创建。即使使用Git或Subversion存储库作为包源代码的输入，Buildroot也会创建一个tarball，然后像往常一样使用tarball。

当Buildroot主要用作集成工具时，这种行为非常适合构建和集成嵌入式Linux系统的所有组件。但是，如果在开发系统的某些组件的过程中使用Buildroot，这种行为就不太方便了：人们会喜欢对一个软件包的源代码进行一些小改动，并且能够使用Buildroot快速重建系统。

直接进行更改output/build/-不是一个合适的解决方案，因为此目录已被删除make clean。

因此，Buildroot为此用例提供了一种特定的机制：_OVERRIDE_SRCDIR机制。Buildroot读取覆盖 文件，允许用户告诉Buildroot某些包的源位置。默认情况下，此覆盖文件已命名 local.mk并位于Buildroot源树的顶级目录中，但可以通过BR2_PACKAGE_OVERRIDE_FILE配置选项指定其他位置 。

在这个覆盖文件中，Buildroot希望找到该表单的行：

_OVERRIDE_SRCDIR = / path / to / pkg1 / sources
_OVERRIDE_SRCDIR = / path / to / pkg2 / sources
例如：

LINUX_OVERRIDE_SRCDIR = / home / bob / linux /
BUSYBOX_OVERRIDE_SRCDIR = / home / bob / busybox /
当Buildroot发现对于给定的包 _OVERRIDE_SRCDIR已定义时，它将不再尝试下载，提取和修补包。相反，它将直接使用指定目录中可用的源代码，并且make clean 不会触及此目录。这允许将Buildroot指向您自己的目录，可以通过Git，Subversion或任何其他版本控制系统进行管理。为此，Buildroot将使用rsync将组件的源代码从指定复制 _OVERRIDE_SRCDIR到output/build/-custom/。

此机制最好make -rebuild与make -reconfigure目标一起使用。甲make -rebuild all序列将rsync的从源代码 _OVERRIDE_SRCDIR到output/build/-custom（感谢 rsync的，仅修改过的文件被复制），并重新启动只是这个包的构建过程。

在linux上面的包的示例中，开发人员可以更改源代码/home/bob/linux然后运行：

make linux-rebuild all
并在几秒钟内获得更新的Linux内核映像 output/images。同样，可以对以下内容中的BusyBox源代码进行更改/home/bob/busybox：

make busybox-rebuild all
根文件系统映像output/images包含更新的BusyBox。

大型项目的源代码树通常包含数百或数千个不需要构建的文件，但会减慢使用rsync复制源代码的过程。可选地，可以定义 _OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS跳过从源树同步某些文件。例如，在处理webkitgtk 包时，以下内容将从本地WebKit源树中排除测试和树内构建：

WEBKITGTK_OVERRIDE_SRCDIR = / home / bob / WebKit
WEBKITGTK_OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS =
–exclude JSTests --exclude ManualTests --exclude PerformanceTests
–exclude WebDriverTests --exclude WebKitBuild --exclude WebKitLibraries
–exclude WebKit.xcworkspace --exclude Websites --exclude examples
第9章特定于项目的自定义
您可能需要为给定项目执行的典型操作是：

配置Buildroot（包括构建选项和工具链，引导加载程序，内核，包和文件系统映像类型选择）
配置其他组件，如Linux内核和BusyBox
自定义生成的目标文件系统

在目标文件系统上添加或覆盖文件（使用 BR2_ROOTFS_OVERLAY）
修改或删除目标文件系统上的文件（使用 BR2_ROOTFS_POST_BUILD_SCRIPT）
在生成文件系统映像之前运行任意命令（使用BR2_ROOTFS_POST_BUILD_SCRIPT）
设置文件权限和所有权（使用 BR2_ROOTFS_DEVICE_TABLE）
添加自定义设备节点（使用 BR2_ROOTFS_STATIC_DEVICE_TABLE）
添加自定义用户帐户（使用BR2_ROOTFS_USERS_TABLES）
生成文件系统映像后运行任意命令（使用BR2_ROOTFS_POST_IMAGE_SCRIPT）
将项目特定的补丁添加到某些包中（使用 BR2_GLOBAL_PATCH_DIR）
添加特定于项目的包
关于此类项目特定自定义的重要说明：请仔细考虑哪些更改确实是项目特定的，哪些更改对项目外的开发人员也有用。Buildroot社区强烈建议并鼓励对Buildroot官方项目进行改进，包和板支持的上游。当然，上游有时是不可能或不可取的，因为这些变化是高度特定的或专有的。

本章介绍如何在Buildroot中进行此类特定于项目的自定义，以及如何以可重现的方式构建相同图像的方式存储它们，即使在运行make clean之后也是如此。通过遵循推荐的策略，您甚至可以使用相同的Buildroot树来构建多个不同的项目！

9.1。推荐的目录结构
为项目自定义Buildroot时，您将创建一个或多个需要存储在某处的项目特定文件。虽然大多数这些文件可以放在任何位置，因为它们的路径将在Buildroot配置中指定，但Buildroot开发人员建议使用本节中描述的特定目录结构。

正交到这个目录结构，你可以选择在那里你把这个结构本身：使用BR2外部的树无论是Buildroot里面树中，或外部的它。这两个选项都是有效的，选择取决于您。

• • 板/
    | + - <公司> /
    | + - /
    | + - linux.config
    | + - busybox.config
    | + - <其他配置文件>
    | + - post_build.sh
    | + - post_image.sh
    | + - rootfs_overlay /
    | | + - etc /
    | | + -
    | + - 补丁/
    | + - foo /
    | | + -
    | + - libbar /
    | + - <其他一些补丁>
    |
• • 配置/
    | + - _defconfig
    |
• • 包/
    | + - <公司> /
    | + - Config.in（如果不使用br2外部树）
    | + - .mk（如果不使用br2外部树）
    | + - package1 /
    | | + - Config.in
    | | + - package1.mk
    | + - package2 /
    | + - Config.in
    | + - package2.mk
    |
• • Config.in（如果使用br2外部树）
• • external.mk（如果使用br2外部树）
    有关上述文件的详细信息，请参阅本章。

注意：如果您选择将此结构放在Buildroot树之外但在br2外部树中，则和可能组件可能是多余的，可以省略。

9.1.1。实现分层自定义
对于用户而言，具有部分需要相同定制的若干相关项目是很常见的。不是为每个项目复制这些自定义，而是建议使用分层自定义方法，如本节中所述。

几乎所有Buildroot中可用的自定义方法（如构建后脚本和根文件系统叠加）都接受以空格分隔的项列表。始终按从左到右的顺序处理指定的项目。通过创建多个此类项目（一个用于常见自定义项，另一个用于实际项目特定的自定义项），可以避免不必要的重复。每个层通常由内部的单独目录体现 board//。根据您的项目，您甚至可以引入两个以上的图层。

用户具有两个常用和foob​​oard定制层的示例目录结构是：

• • 板/
  • • <公司> /
    • • 普通/
        | + - post_build.sh
        | + - rootfs_overlay /
        | | + - …
        | + - 补丁/
        | + - …
        |
    • • fooboard /
      • • linux.config
      • • busybox.config
      • • <其他配置文件>
      • • post_build.sh
      • • rootfs_overlay /
          | + - …
      • • 补丁/
        • • …
            例如，如果用户将BR2_GLOBAL_PATCH_DIR配置选项设置为：

BR2_GLOBAL_PATCH_DIR =“board / / common / patches board / / fooboard / patches”
然后首先应用来自公共层的补丁，然后是来自foob​​oard层的补丁。

9.2。在Buildroot之外保留自定义
正如第9.1节“推荐目录结构”中简要提到的那样，您可以将项目特定的自定义项放在两个位置：

直接在Buildroot树中，通常使用版本控制系统中的分支维护它们，以便轻松升级到较新的Buildroot版本。
在Buildroot树之外，使用br2外部机制。此机制允许将程序包配方，板支持和配置文件保留在Buildroot树之外，同时仍然可以将它们很好地集成到构建逻辑中。我们将此位置称为br2外部树。本节介绍如何使用br2外部机制以及在br2外部树中提供的内容。
通过将BR2_EXTERNALmake变量设置为要使用的br2外部树的路径，可以告诉Buildroot使用一个或多个br2外部树。它可以传递给任何Buildroot make调用。它会自动保存在.br-external.mk输出目录的隐藏文件中。多亏了这一点，没有必要BR2_EXTERNAL在每次make调用时都通过。但是，它可以随时通过传递新值进行更改，并可以通过传递空值来删除。

注意。 br2外部树的路径可以是绝对的也可以是相对的。如果它作为相对路径传递，请务必注意它是相对于主Buildroot源目录而不是 Buildroot输出目录解释的。

注意： 如果在Buildroot 2016.11之前使用br2外部树，则需要先将其转换为可以在Buildroot 2016.11之后使用它。有关这样做的帮助，请参见 第25.1节“迁移到2016.11”。

一些例子：

buildroot / $ make BR2_EXTERNAL = / path / to / foo menuconfig
从现在开始，/path/to/foo将使用br2外部树的定义：

buildroot / $ make
buildroot / $ make legal-info
我们可以随时切换到另一个br2外部树：

buildroot / $ make BR2_EXTERNAL = / where / we / have / bar xconfig
我们还可以使用多个br2外部树：

buildroot / $ make BR2_EXTERNAL = / path / to / foo：/ where / we / have / bar menuconfig
或禁用任何br2外部树的使用：

buildroot / $ make BR2_EXTERNAL = xconfig
9.2.1。br2外部树的布局
br2外部树必须至少包含这三个文件，如以下章节所述：

external.desc
external.mk
Config.in
除了这些必需文件之外，可能还存在可能存在于br2外部树中的其他和可选内容，例如configs/ 目录。它们也在以下章节中描述。

稍后还将描述完整的示例br2外部树布局。

该external.desc文件
该文件描述了br2外部树：该br2外部树的名称和描述 。

此文件的格式是基于行的，每行以关键字开头，后跟冒号和一个或多个空格，后跟分配给该关键字的值。目前已识别出两个关键字：

name，mandatory，定义该br2外部树的名称。该名称只能在集合中使用ASCII字符[A-Za-z0-9_]; 禁止任何其他角色。Buildroot将变量设置为 BR2_EXTERNAL_$(NAME)_PATHbr2外部树的绝对路径，以便您可以使用它来引用br2外部树。此变量在Kconfig中都可用，因此您可以使用它来获取Kconfig文件（见下文）和Makefile，以便您可以使用它来包含其他Makefile（参见下文）或引用其他文件（如数据文件） ）来自你的外部树。

注意： 由于可以同时使用多个br2外部树，因此Buildroot使用此名称为每个树生成变量。该名称用于标识您的br2外部树，因此请尝试提供一个真正描述您的br2外部树的名称，以使其相对独特，以便它不会与另一个br2中的其他名称冲突 - 外部树，特别是如果您计划以某种方式与第三方共享您的br2外部树或使用来自第三方的br2外部树。

desc，optional，提供该br2外部树的简短描述。它应该适合单行，大多是自由格式（见下文），用于显示有关br2外部树的信息（例如，在defconfig文件列表上方，或者作为menuconfig中的提示）; 因此，它应该相对简短（40个字符可能是一个很好的上限）。BR2_EXTERNAL_KaTeX parse error: Expected group after '_' at position 40: …和相应BR2_EXTERNAL_̲(NAME)_PATH 变量的示例：

FOO → BR2_EXTERNAL_FOO_PATH
BAR_42 → BR2_EXTERNAL_BAR_42_PATH
在以下示例中，假定要设置的名称BAR_42。

注： 这两个BR2_EXTERNAL_KaTeX parse error: Expected group after '_' at position 25: …TH和BR2_EXTERNAL_̲(NAME)_DESC是在的Kconfig文件和Makefile文件可用。它们也可以在环境中导出，因此可以在构建后，后映像和fakeroot脚本中使用。

在Config.in和external.mk文件
这些文件（可能都是空的）可用于定义包配方（即foo/Config.in，foo/foo.mk对于捆绑在Buildroot本身中的包）或其他自定义配置选项或make逻辑。

Buildroot自动包含Config.in每个br2外部树，使其显示在顶级配置菜单中，并包含external.mk每个br2外部树与其余makefile逻辑。

这个的主要用途是存储包装食谱。建议的方法是编写一个如下所示的Config.in文件：

源“$ BR2_EXTERNAL_BAR_42_PATH / package / package1 / Config.in”
源“$ BR2_EXTERNAL_BAR_42_PATH / package / package2 / Config.in”
然后，有一个external.mk看起来像这样的文件：

包括$（sort $（通配符$（BR2_EXTERNAL_BAR_42_PATH）/ package / * / *。mk））
然后进入$(BR2_EXTERNAL_BAR_42_PATH)/package/package1并 $(BR2_EXTERNAL_BAR_42_PATH)/package/package2创建正常的Buildroot包配方，如第17章“ 向Buildroot添加新包”中所述。如果您愿意，还可以在名为的子目录中对包进行分组，并相应地调整上述路径。

您还可以在其中定义自定义配置选项Config.in和自定义make逻辑external.mk。

该configs/目录
可以将buildroot defconfigs存储configs在br2外部树的子目录中。Buildroot会自动在输出中显示它们，make list-defconfigs并允许它们加载正常make _defconfig命令。它们将在make list-defconfigs输出中显示，该 输出位于External configs包含它们所定义的br2外部树的名称的标签下方。

注意： 如果defconfig文件存在于多个br2外部树中，则使用最后一个br2外部树中的defconfig文件。因此可以覆盖Buildroot或其他br2外部树中捆绑的defconfig。

自由格式的内容
可以在那里存储所有特定于板的配置文件，例如内核配置，根文件系统覆盖，或Buildroot允许设置位置的任何其他配置文件（通过使用BR2_EXTERNAL_$(NAME)_PATH变量）。例如，您可以将路径设置为全局修补程序目录，rootfs覆盖以及内核配置文件，如下所示（例如，通过运行 make menuconfig并填写这些选项）：

BR2_GLOBAL_PATCH_DIR = $（BR2_EXTERNAL_BAR_42_PATH）/补丁/
BR2_ROOTFS_OVERLAY = $（BR2_EXTERNAL_BAR_42_PATH）/板/ /重叠/
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE = $（BR2_EXTERNAL_BAR_42_PATH）/板/ /kernel.config
示例布局
下面是使用br2-external的所有功能的示例布局（示例内容显示在它上面的文件中，当它与解释br2外部树相关时;这完全是为了说明而完全由课程）：

/路径/到/ BR2-EXT树/
| - external.desc
| |名称：BAR_42
| | desc：示例br2外部树
| ---- | | - Config.in | | source“$ BR2_EXTERNAL_BAR_42_PATH / package / pkg-1 / Config.in” | | source“$ BR2_EXTERNAL_BAR_42_PATH / package / pkg-2 / Config.in” | | | | config BAR_42_FLASH_ADDR | | 十六进制“my-board flash address” | | 默认为0x10AD |----
|
| - external.mk
| | include $（sort $（通配符$（BR2_EXTERNAL_BAR_42_PATH）/ package / * / *。mk））
| |
| |闪光我的板：
| | $（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 | | 布尔“pkg-1” | | 救命 | | 一些关于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||-configs/my-boar{d}_{d}efconfig||BR{2}_{G}LOBA{L}_{P}ATC{H}_{D}IR=“$（BR2_EXTERNAL_BAR_42_PATH）/补丁/”
| | BR2_ROOTFS_OVERLAY = “$（BR{2}_{E}XTERNA{L}_{B}A{R}_4{2}_{P}ATH）/板/我的板/覆盖/”||BR{2}_{R}OOTF{S}_{P}OS{T}_{I}MAG{E}_{S}CRIPT=“$（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
`----
然后，在menuconfig中可以看到br2外部树（扩展了布局）：

外部选项—>
***示例br2外部树（在/ path / to / br2-ext-tree /中）
[] pkg-1
[] pkg-2
（0x10AD）我的主板闪存地址
如果您使用多个br2外部树，它将看起来像（扩展布局，第二个具有名称FOO_27但没有 desc:字段external.desc）：

外部选项—>
示例br2-外部树—>
***示例br2外部树（在/ path / to / br2-ext-tree中）
[] pkg-1
[] pkg-2
（0x10AD）我的主板闪存地址
FOO_27 —>
*** FOO_27（在/ path / to / another-br2-ext中）
[] foo
[]吧
9.3。存储Buildroot配置
可以使用该命令存储Buildroot配置 make savedefconfig。

这通过删除默认值的配置选项来删除Buildroot配置。结果存储在一个名为的文件中defconfig。如果要将其保存在其他位置，请更改BR2_DEFCONFIGBuildroot配置本身中的 选项，或者调用make with make savedefconfig BR2_DEFCONFIG=。

存储此defconfig的推荐位置是 configs/_defconfig。如果您遵循此建议，将列出配置make help，并可通过运行再次设置make _defconfig。

或者，您可以将文件复制到任何其他位置并使用重建 make defconfig BR2_DEFCONFIG=。

9.4。存储其他组件的配置
如果更改了BusyBox，Linux内核，Barebox，U-Boot和uClibc的配置文件也应该存储。对于这些组件中的每一个，存在Buildroot配置选项以指向输入配置文件，例如BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE。要存储其配置，请将这些配置选项设置为要保存配置文件的路径，然后使用下面描述的帮助程序目标实际存储配置。

如第9.1节“推荐的目录结构”中所述，存储这些配置文件的建议路径是 board///foo.config。

确保在更改BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILEetc选项之前创建配置文件。否则，Buildroot将尝试访问此配置文件，该文件尚不存在，并且将失败。您可以通过运行make linux-menuconfig等来创建配置文件 。

Buildroot提供了一些帮助目标，可以更轻松地保存配置文件。

make linux-update-defconfig将linux配置保存到指定的路径BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE。它通过删除默认值简化了配置文件。但是，这仅适用于从2.6.33开始的内核。对于早期的内核，请使用make linux-update-config。
make busybox-update-config将busybox配置保存到指定的路径BR2_PACKAGE_BUSYBOX_CONFIG。
make uclibc-update-config将uClibc配置保存到指定的路径BR2_UCLIBC_CONFIG。
make barebox-update-defconfig将裸箱配置保存到指定的路径BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE。
make uboot-update-defconfig将U-Boot配置保存到指定的路径BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE。
对于at91bootstrap3，不存在任何帮助程序，因此您必须手动将配置文件复制到BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE。
9.5。自定义生成的目标文件系统
除了更改配置之外make *config，还有一些其他方法可以自定义生成的目标文件系统。

可以共存的两种推荐方法是根文件系统覆盖和后构建脚本。

根文件系统覆盖（BR2_ROOTFS_OVERLAY）
文件系统覆盖是一个文件树，在构建之后直接在目标文件系统上复制。要启用此功能，请将配置选项BR2_ROOTFS_OVERLAY（在System configuration菜单中）设置为叠加层的根目录。您甚至可以指定多个叠加，以空格分隔。如果指定相对路径，则它将相对于Buildroot树的根。版本控制系统的隐藏目录，如.git，.svn，.hg，等，称为文件.empty和结束文件~从副本中排除。

如第9.1节“推荐的目录结构”所示，此叠加层的推荐路径为board///rootfs-overlay。

后构建脚本（BR2_ROOTFS_POST_BUILD_SCRIPT）
构建后脚本是在 Buildroot构建所有选定软件之后但在组装rootfs映像之前调用的shell脚本。要启用此功能，请在config选项中指定以空格分隔的构建后脚本列表BR2_ROOTFS_POST_BUILD_SCRIPT（在System configuration菜单中）。如果指定相对路径，则它将相对于Buildroot树的根。

使用构建后脚本，您可以删除或修改目标文件系统中的任何文件。但是，您应该谨慎使用此功能。每当您发现某个包生成错误或不需要的文件时，您应该修复该包，而不是使用一些构建后的清理脚本来解决它。

如第9.1节“推荐的目录结构”所示，此脚本的推荐路径为board///post_build.sh。

后构建脚本以主Buildroot树作为当前工作目录运行。目标文件系统的路径作为第一个参数传递给每个脚本。如果config选项 BR2_ROOTFS_POST_SCRIPT_ARGS不为空，则这些参数也将传递给脚本。所有脚本都将传递完全相同的参数集，不可能将不同的参数集传递给每个脚本。

此外，您还可以使用以下环境变量：

BR2_CONFIG：Buildroot .config文件的路径
HOST_DIR，STAGING_DIR，TARGET_DIR：见 第17.5.2，“ generic-package参考”
BUILD_DIR：提取和构建包的目录
BINARIES_DIR：存储所有二进制文件（即图像）的位置
BASE_DIR：基本输出目录
下面介绍了另外三种自定义目标文件系统的方法，但不推荐使用它们。

直接修改目标文件系统
对于临时修改，您可以直接修改目标文件系统并重建映像。目标文件系统可用于output/target/。进行更改后，运行make以重建目标文件系统映像。

此方法允许您对目标文件系统执行任何操作，但如果需要使用清理Buildroot树make clean，则这些更改将丢失。在某些情况下需要进行此类清洁，有关详细信息，请参见第8.2节“了解何时需要完全重建”。因此，此解决方案仅对快速测试有用：更改无法在make clean 命令中生效。验证完更改后，应确保它们在make clean使用根文件系统覆盖或后构建脚本后仍然存在。

自定义目标骨架（BR2_ROOTFS_SKELETON_CUSTOM）
根文件系统映像是从目标框架创建的，所有软件包都在其上安装文件。在output/target构建和安装任何包之前，将骨架复制到目标目录。默认目标框架提供标准的Unix文件系统布局和一些基本的init脚本和配置文件。

如果默认骨架（在下面可用system/skeleton）与您的需求不匹配，您通常会使用根文件系统覆盖或后构建脚本来调整它。但是，如果默认骨架与您需要的完全不同，则使用自定义骨架可能更合适。

要启用此功能，请启用配置选项 BR2_ROOTFS_SKELETON_CUSTOM并设置BR2_ROOTFS_SKELETON_CUSTOM_PATH 为自定义骨架的路径。System configuration菜单中提供了这两个选项 。如果指定相对路径，则它将相对于Buildroot树的根。

建议不要使用此方法，因为它会复制整个框架，这会阻止利用在以后的Buildroot版本中为默认框架带来的修复或改进。

post-fakeroot脚本（BR2_ROOTFS_POST_FAKEROOT_SCRIPT）
在聚合最终映像时，进程的某些部分需要root权限：创建设备节点/dev，设置文件和目录的权限或所有权…为了避免需要实际的root权限，Buildroot用于fakeroot模拟root权限。这不是完全替代实际的root，但足以满足Buildroot的需求。

post-fakeroot脚本是shell脚本，在fakeroot阶段结束时调用，就在调用文件系统映像生成器之前。因此，它们在fakeroot上下文中被调用。

如果您需要调整文件系统以进行通常仅对root用户可用的修改，则后fakeroot脚本非常有用。

注意： 建议使用现有机制设置文件权限或创建条目/dev（请参见第9.5.1节“设置文件权限和所有权以及添加自定义设备节点”）或创建用户（请参见第9.6节“添加自定义”）用户帐户“）

注意： 构建后脚本（上面）和fakeroot脚本之间的区别在于，未在fakeroot上下文中调用构建后脚本。

注意;。 使用fakeroot并不是实际成为root的绝对替代品。 fakeroot只伪造文件访问权限和类型（常规，块或char设备…）和uid / gid; 这些是在内存中模拟的。

9.5.1。设置文件权限和所有权以及添加自定义设备节点
有时需要在文件或设备节点上设置特定权限或所有权。例如，某些文件可能需要由root拥有。由于后构建脚本不是以root身份运行，因此除非您使用构建后脚本中的显式fakeroot，否则无法从那里进行此类更改。

相反，Buildroot为所谓的权限表提供支持。要使用此功能，请将config选项设置BR2_ROOTFS_DEVICE_TABLE为以空格分隔的权限表列表，遵循makedev语法 第23章Makedev语法文档的常规文本文件。

如果您正在使用静态设备表（即不使用devtmpfs, mdev或(e)udev），则可以在所谓的设备表中使用相同的语法添加设备节点。要使用此功能，请将config选项设置BR2_ROOTFS_STATIC_DEVICE_TABLE为以空格分隔的设备表列表。

如第9.1节“推荐的目录结构”所示，此类文件的推荐位置为board///。

应该注意的是，如果特定权限或设备节点与特定应用程序相关，则应该设置变量 FOO_PERMISSIONS并FOO_DEVICES在包的.mk文件中（参见第17.5.2节“ generic-package引用”）。

9.6。添加自定义用户帐户
有时需要在目标系统中添加特定用户。为了满足此要求，Buildroot为所谓的用户表提供支持 。要使用此功能，请将config选项设置 BR2_ROOTFS_USERS_TABLES为以空格分隔的用户表列表，遵循makeuse语法 第24章，Makeusers语法文档的常规文本文件。

如第9.1节“推荐的目录结构”所示，此类文件的推荐位置为board///。

应该注意的是，如果自定义用户与特定应用程序相关，则应该FOO_USERS在包的.mk 文件中设置变量（参见第17.5.2节“ generic-package引用”）。

9.7。创建图像后的自定义
在构建 文件系统映像，内核和引导加载程序之前运行构建后脚本（第9.5节“自定义生成的目标文件系统”），后映像脚本可用于在创建所有映像后执行某些特定操作。

例如，后映像脚本可用于在NFS服务器导出的位置自动提取根文件系统tarball，或创建捆绑根文件系统和内核映像的特殊固件映像，或项目所需的任何其他自定义操作。

要启用此功能，请在config选项中指定一个以空格分隔的后映像脚本列表BR2_ROOTFS_POST_IMAGE_SCRIPT（在System configuration菜单中）。如果指定相对路径，则它将相对于Buildroot树的根。

就像构建后脚本一样，后映像脚本与主Buildroot树一起作为当前工作目录运行。images 输出目录的路径作为第一个参数传递给每个脚本。如果config选项BR2_ROOTFS_POST_SCRIPT_ARGS不为空，则这些参数也将传递给脚本。所有脚本都将传递完全相同的参数集，不可能将不同的参数集传递给每个脚本。

同样，就像在生成后的脚本，这些脚本可以访问的环境变量BR2_CONFIG，HOST_DIR，STAGING_DIR， TARGET_DIR，BUILD_DIR，BINARIES_DIR和BASE_DIR。

后映像脚本将作为执行Buildroot的用户执行，而Buildroot通常不应该是root用户。因此，在其中一个脚本中需要root权限的任何操作都需要特殊处理（使用fakeroot或sudo），这由脚本开发人员处理。

9.8。添加项目特定的修补程序
有时将额外的补丁应用于包 - 在Buildroot中提供的补丁之上。例如，这可能用于支持项目中的自定义功能，或者在处理新体系结构时。

的BR2_GLOBAL_PATCH_DIR配置选项可用于指定包含包贴片的一个或多个目录的空间分隔的列表。

对于特定软件包的特定版本， 将按如下方式应用修补程序BR2_GLOBAL_PATCH_DIR：

对于每个目录 - 存在于 BR2_GLOBAL_PATCH_DIR，a 将确定如下：

/// 如果目录存在。
否则，/如果目录存在。
然后将从以下应用补丁：

如果series包目录中存在文件，则根据该series文件应用补丁;
否则，匹配的补丁文件*.patch按字母顺序应用。因此，为了确保以正确的顺序应用它们，强烈建议将补丁文件命名为： -.patch，其中指的是 应用顺序。
有关如何为程序包应用修补程序的信息，请参见 第18.2节“如何应用修补程序”

该BR2_GLOBAL_PATCH_DIR选项是为包指定自定义修补程序目录的首选方法。它可用于为buildroot中的任何包指定补丁目录。它还应该用于代替U-Boot和Barebox等软件包可用的自定义修补程序目录选项。通过这样做，它将允许用户从一个顶级目录管理他们的补丁。

BR2_GLOBAL_PATCH_DIR作为指定自定义补丁的首选方法的例外是BR2_LINUX_KERNEL_PATCH。 BR2_LINUX_KERNEL_PATCH应该用于指定URL中可用的内核补丁。注意： BR2_LINUX_KERNEL_PATCH指定在可用修补程序之后应用的内核修补程序BR2_GLOBAL_PATCH_DIR，因为它是从Linux程序包的修补程序后挂钩完成的。

9.9。添加特定于项目的包
通常，任何新包都应直接添加到package 目录中并提交给Buildroot上游项目。第17章“ 向Buildroot添加新包”中详细介绍了如何将包添加到Buildroot中 ，这里不再重复。但是，您的项目可能需要一些无法升级的专有软件包。本节将说明如何将这些特定于项目的包保留在特定于项目的目录中。

如第9.1节“推荐目录结构”所示，项目特定包的推荐位置是package//。如果您正在使用br2外部树功能（请参见第9.2节“在Buildroot 之外保留自定义”），建议的位置是将它们放在package/br2外部树中命名的子目录中。

但是，除非我们执行一些额外的步骤，否则Buildroot将不会知道此位置中的软件包。如 第17章“ 向Buildroot添加新包”中所述，Buildroot中的包基本上由两个文件组成：一个.mk文件（描述如何构建包）和一个 Config.in文件（描述该包的配置选项）。

Buildroot将自动将.mk文件包含在目录的第一级子目录中package（使用模式 package//.mk）。如果我们希望Buildroot包含.mk来自更深层子目录的文件（例如package//package1/），那么我们只需要.mk在包含这些附加.mk文件的第一级子目录中添加文件。因此，创建一个package//.mk包含以下内容的文件 （假设您下面只有一个额外的目录级别package//）：

包括$（sort $（通配符包/ / * / * .mk））
对于Config.in文件，创建一个package//Config.in 包含Config.in所有包的文件的文件。必须提供详尽的列表，因为kconfig的source命令不支持通配符。例如：

源“package / /package1/Config.in”
源“package / /package2/Config.in”
包括这个新文件package//Config.in从 package/Config.in，最好是在一个特定的公司菜单进行合并与未来Buildroot里面的版本更容易。

如果使用br2外部树，请参见第9.2节“在Buildroot 之外保留自定义”以了解如何填写这些文件。

9.10。存储项目特定自定义的快速指南
本章前面已经介绍了制作项目特定自定义的不同方法。本节将通过提供存储项目特定自定义的逐步说明来总结所有这些内容。显然，可以跳过与项目无关的步骤。

make menuconfig 配置工具链，包和内核。
make linux-menuconfig 更新内核配置，类似于其他配置，如busybox，uclibc，…
mkdir -p board//
将以下选项设置为board///.config （只要它们相关）：

BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
BR2_PACKAGE_BUSYBOX_CONFIG
BR2_UCLIBC_CONFIG
BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE
BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE
BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE
写配置文件：

make linux-update-defconfig
make busybox-update-config
make uclibc-update-config
cp /build/at91bootstrap3-*/.config board///at91bootstrap3.config
make barebox-update-defconfig
make uboot-update-defconfig
board///rootfs-overlay/使用rootfs上需要的其他文件 创建并填充它，例如 board///rootfs-overlay/etc/inittab。设置BR2_ROOTFS_OVERLAY 为board///rootfs-overlay。
创建一个构建后的脚本 board///post_build.sh。设置 BR2_ROOTFS_POST_BUILD_SCRIPT为 board///post_build.sh
如果必须设置其他setuid权限或必须创建设备节点，请创建board///device_table.txt 并添加该路径BR2_ROOTFS_DEVICE_TABLE。
如果必须创建其他用户帐户，请创建 board///users_table.txt并添加该路径BR2_ROOTFS_USERS_TABLES。
要添加自定义补丁的某些包，设置BR2_GLOBAL_PATCH_DIR 到board///patches/并添加你的补丁为每个包的包名命名的子目录。应该调用每个补丁--.patch。
特别是对于Linux内核，还存在一个选项 BR2_LINUX_KERNEL_PATCH，主要优点是它还可以从URL下载补丁。如果您不需要， BR2_GLOBAL_PATCH_DIR则首选。U-Boot，Barebox，at91bootstrap和at91bootstrap3也有单独的选项，但这些选项没有提供任何优势，BR2_GLOBAL_PATCH_DIR并且可能在将来被删除。
如果需要添加特定于项目的包，请创建包 package//并将其放在该目录中。创建一个.mk包含.mk所有包的文件的整体文件。创建一个整体 Config.in文件，用于获取Config.in所有包的文件。Config.in从Buildroot的 package/Config.in文件中包含此文件。
make savedefconfig 保存buildroot配置。
cp defconfig configs/_defconfig
第10章常见问题和故障排除
10.1。启动网络后启动挂起…
如果启动过程似乎在以下消息之后挂起（消息不一定完全相似，具体取决于所选包的列表）：

释放init内存：3972K
初始化随机数生成器…完成。
启动网络…
启动dropbear sshd：生成rsa密钥…生成dsa密钥…好的
那么这意味着您的系统正在运行，但没有在串行控制台上启动shell。为了让系统在串行控制台上启动shell，您必须进入Buildroot配置，在 子菜单中System configuration修改Run a getty (login prompt) after boot 并设置相应的端口和波特率getty options。这将自动调整/etc/inittab生成的系统的文件，以便shell在正确的串行端口上启动。

10.2。为什么目标上没有编译器？
已经决定从Buildroot-2012.11版本中停止对目标上的本机编译器的支持，因为：

这个特征既没有维护也没有经过测试，经常被打破;
此功能仅适用于Buildroot工具链;
Buildroot主要针对小型或非常小的目标硬件，板载资源有限（CPU，内存，大容量存储），对目标进行编译没有多大意义;
Buildroot旨在简化交叉编译，使目标上的本地编译变得不必要。
如果你的目标上还需要编译器，那么Buildroot不适合你的目的。在这种情况下，您需要一个真正的发行版，您应该选择以下内容：

OpenEmbedded的
yocto
emdebian
Fedora的
openSUSE ARM
Arch Linux ARM
…
10.3。为什么目标上没有开发文件？
由于目标上没有可用的编译器（请参见 第10.2节“为什么目标上没有编译器？”），因此使用标头或静态库浪费空间是没有意义的。

因此，自Buildroot-2012.11发行版以来，始终会从目标中删除这些文件。

10.4。为什么目标没有文档？
由于Buildroot主要针对板载资源有限（CPU，内存，大容量存储）的小型或非常小的目标硬件，因此使用文档数据浪费空间是没有意义的。

如果您无论如何都需要目标上的文档数据，那么Buildroot不适合您的目的，您应该寻找真正的分布（参见：第10.2节“为什么目标上没有编译器？”）。

10.5。为什么在Buildroot配置菜单中看不到某些包？
如果Buildroot树中存在一个包但未出现在配置菜单中，则这很可能意味着某些包的依赖关系未得到满足。

要了解有关包的依赖关系的更多信息，请在配置菜单中搜索包符号（请参见第8.1节“ 制作提示”）。

然后，您可能必须递归地启用多个选项（对应于未满足的依赖项）才能最终选择包。

如果由于某些未满足的工具链选项而无法看到包，那么您当然应该运行完全重建（有关更多说明，请参见第8.1节“ make tips”）。

10.6。为什么不将目标目录用作chroot目录？
有很多理由不使用目标目录chroot one，其中包括：

文件所有权，模式和权限未在目标目录中正确设置;
设备节点未在目标目录中创建。
由于这些原因，使用目标目录作为新根目录的chroot命令很可能会失败。

如果要在chroot内部或作为NFS根目录运行目标文件系统，请使用生成的tarball映像images/并以root身份提取它。

10.7。为什么Buildroot不生成二进制包（.deb，.ipkg …）？
Buildroot列表中经常讨论的一个功能是“包管理”的一般主题。总而言之，我们的想法是添加一些跟踪哪些Buildroot软件包安装哪些文件，目标是：

当从menuconfig中取消选择此包时，能够删除包安装的文件;
能够生成可以安装在目标上的二进制包（ipk或其他格式），而无需重新生成新的根文件系统映像。
一般来说，大多数人认为这很容易：只需跟踪哪个软件包安装了什么，并在取消选择软件包时将其删除。但是，它要复杂得多：

它不仅涉及target/目录，还涉及sysroot host//sysroot和host/目录本身。必须跟踪由各种包安装在这些目录中的所有文件。
从配置中取消选择包时，仅删除它安装的文件是不够的。还必须删除所有反向依赖项（即依赖它的包）并重建所有这些包。例如，程序包A可选地依赖于OpenSSL库。两者都被选中，并构建了Buildroot。包A使用OpenSSL以加密支持构建。稍后，OpenSSL从配置中取消选择，但包A仍然存在（因为OpenSSL是一个可选的依赖项，这是可能的。）如果只删除了OpenSSL文件，那么包A安装的文件就会被破坏：它们使用的库是不再出现在目标上。虽然这在技术上是可行的，但它给Buildroot增加了很多复杂性，这与我们试图坚持的简单性相悖。
除了上一个问题之外，还存在Buildroot甚至不知道可选依赖项的情况。例如，版本1.0中的软件包A从未使用过OpenSSL，但在版本2.0中，它会自动使用OpenSSL（如果可用）。如果尚未更新Buildroot .mk文件以将此考虑在内，则程序包A将不会成为OpenSSL的反向依赖项的一部分，并且在删除OpenSSL时不会删除和重建。当然，应修复程序包A的.mk文件以提及此可选依赖项，但同时，您可以拥有不可重现的行为。
该请求还允许在输出目录中应用menuconfig中的更改，而无需从头开始重建所有内容。但是，这很难以可靠的方式实现：当包的子选项发生变化时会发生什么（我们必须检测到这一点，并从头开始重建包，可能还有所有反向依赖），如果工具链选项会发生什么？目前，Buildroot所做的工作清晰简单，因此其行为非常可靠，并且很容易支持用户。如果在下一个make之后应用menuconfig中完成的配置更改，那么它必须在所有情况下正确且正确地工作，并且没有一些奇怪的极端情况。风险是获取错误报告，例如“我已启用包A，B和C，然后运行make，
由于所有这些原因，结论是添加对已安装文件的跟踪以在未选择包时删除它们，或者生成二进制包的存储库，这是非常难以可靠地实现的并且将增加许多复杂性。

在这个问题上，Buildroot开发人员发表了这个立场声明：

Buildroot努力使生成根文件系统变得容易（顺便说一下，这就是名称。）这就是我们想让Buildroot擅长的：构建根文件系统。
Buildroot并不意味着是一个发行版（或者更确切地说，是一个发行版。）大多数Buildroot开发人员都认为这不是我们应该追求的目标。我们相信还有其他工具比Buildroot更适合生成发行版。例如， Open Embedded或openWRT就是这样的工具。
我们更倾向于将Buildroot推向一个简单（甚至更容易）生成完整根文件系统的方向。这就是使Buildroot在人群中脱颖而出的原因（当然，除此之外！）
我们相信，对于大多数嵌入式Linux系统，二进制包不是必需的，并且可能有害。当使用二进制包时，这意味着可以部分升级系统，这会创建大量可能的包版本组合，应该在嵌入式设备上进行升级之前进行测试。另一方面，通过一次升级整个根文件系统映像进行完整的系统升级，部署到嵌入式系统的映像保证真正是经过测试和验证的映像。
10.8。如何加快构建过程？
由于Buildroot通常涉及对整个系统进行可能很长的完全重建，因此我们提供了一些有助于缩短构建时间的技巧：

使用预先构建的外部工具链而不是默认的Buildroot内部工具链。通过使用预构建的Linaro工具链（在ARM上）或Sourcery CodeBench工具链（用于ARM，x86，x86-64，MIPS等），您将在每次完整重建时保存工具链的构建时间，大约15到20分钟。请注意，暂时使用外部工具链并不会阻止您在系统的其余部分工作后切换回内部工具链（可能提供更高级别的自定义）;
使用ccache编译器缓存（请参阅：第8.12.3节“ ccache在Buildroot中使用”）;
了解只重建您真正关心的几个软件包（请参见第8.3节“了解如何重建软件包”），但要注意有时需要完全重建（参见第8.2节“了解何时需要完全重建”）;
确保您没有为用于运行Buildroot的Linux系统使用虚拟机。众所周知，大多数虚拟机技术会对I / O产生显着的性能影响，这对构建源代码非常重要;
确保您只使用本地文件：不要尝试通过NFS进行构建，这会显着降低构建速度。在本地使用Buildroot下载文件夹也有一点帮助。
购买新硬件。SSD和大量RAM是加速构建的关键。
第11章。已知问题
BR2_TARGET_LDFLAGS 如果此类选项包含$符号，则无法传递额外的链接器选项。例如，已知以下内容：BR{2}_{T}ARGE{T}_{L}DFLAGS="-Wl,-rpath{=}^{\prime }$ORIGIN/…/lib’"
libffiSuperH 2和ARC架构不支持 该软件包。
该prboom软件包使用Sourcery CodeBench，版本2012.09中的SuperH 4编译器触发编译器故障。
第12章法律声明和许可
12.1。遵守开源许可证
Buildroot的所有最终产品（工具链，根文件系统，内核，引导加载程序）都包含在各种许可下发布的开源软件。

使用开源软件，您可以自由地构建丰富的嵌入式系统，从各种软件包中进行选择，同时也规定了您必须了解和尊重的一些义务。某些许可证要求您在产品文档中发布许可证文本。其他人则要求您将软件的源代码重新分发给接收产品的人。

每个许可证的具体要求都记录在每个包装中，您有责任（或您的法律办公室）遵守这些要求。为了使您更容易，Buildroot可以为您收集一些您可能需要的材料。要生成此材料，在使用Buildroot配置后make menuconfig，make xconfig或make gconfig运行：

制作法律信息
Buildroot将在legal-info/子目录下的输出目录中收集与法律相关的材料。在那里你会发现：

一个README文件，它汇总了生成的材料，并包含有关Buildroot无法生成的材料的警告。
buildroot.config：这是Buildroot配置文件，通常用make menuconfig它来生成，并且是重现构建所必需的。
所有包的源代码; 这是保存在sources/和 host-sources/分别子目录目标和主机包。设置的包的源代码_REDISTRIBUTE = NO将不会保存。还会保存已应用的修补程序以及名称series 按照应用顺序列出修补程序的文件。修补程序与它们修改的文件具有相同的许可证。注意：Buildroot将其他补丁应用于基于autotools的软件包的Libtool脚本。这些补丁可以support/libtool在Buildroot源代码中找到， 并且由于技术限制，不会随包源一起保存。您可能需要手动收集它们。
清单文件（一个用于主机，一个用于目标包），列出已配置的软件包，其版本，许可证和相关信息。其中一些信息可能未在Buildroot中定义; 这些项目标记为“未知”。
所有软件包的授权协议文本，中licenses/和host-licenses/ 的目标和主机套餐分别子目录。如果未在Buildroot中定义许可证文件，则不会生成该文件，并在其中README显示警告。
请注意，legal-infoBuildroot功能的目的是生成所有与法律合规性相关的材料。Buildroot不会尝试生成您必须以某种方式公开的确切材料。当然，生产的材料多于严格遵守法律所需的材料。例如，它生成在类似BSD的许可证下发布的包的源代码，您不需要以源代码形式重新分发。

此外，由于技术限制，Buildroot不会生成您将要或可能需要的某些材料，例如工具链源代码和Buildroot源代码本身（包括需要源分发的包的补丁）。运行时make legal-info，Buildroot会在README 文件中生成警告，以通知您无法保存的相关材料。

最后，请记住，输出make legal-info是基于每个包装配方中的声明性语句。Buildroot开发人员尽其所能尽力保持这些声明性陈述尽可能准确。但是，这些陈述性陈述很可能不完全准确，也不详尽。您（或您的法律部门）在将其用作您自己的合规交付之前必须检查输出make legal-info。请参阅Buildroot发行版根目录下的文件中的NO WARRANTY子句（第11和12节）COPYING。

12.2。遵守Buildroot许可证
Buildroot本身是一个开源软件，根据 GNU通用公共许可证，版本2或（根据您的选择）任何更高版本发布，但下面详述的软件包补丁除外。但是，作为构建系统，它通常不是最终产品的一部分：如果您为设备开发根文件系统，内核，引导加载程序或工具链，则Buildroot的代码仅存在于开发计算机上，而不存在于设备存储中。

尽管如此，Buildroot开发人员的一般观点是，在发布包含GPL许可软件的产品时，您应该发布Buildroot源代码以及其他软件包的源代码。这是因为 GNU GPL 将可执行工作的“ 完整源代码 ” 定义为“ 它包含的所有模块的所有源代码，以及任何相关的接口定义文件，以及用于控制可执行文件的编译和安装的脚本 ”。Buildroot是用于控制可执行文件的编译和安装的脚本的一部分，因此它被认为是必须重新分发的材料的一部分。

请记住，这只是Buildroot开发人员的意见，如有任何疑问，您应咨询您的法律部门或律师。

12.2.1。补丁包
Buildroot还捆绑了补丁文件，这些补丁文件应用于各种软件包的源代码。这些补丁不包含在Buildroot的许可证中。相反，它们由应用修补程序的软件的许可证涵盖。当所述软件在多个许可下可用时，Buildroot补丁仅在可公开访问的许可下提供。

有关技术详细信息，请参见第18章，修补包。

第13章超越Buildroot
13.1。引导生成的图像
13.1.1。NFS启动
要实现NFS-boot，请在Filesystem映像菜单中启用tar root filesystem。

完成构建后，只需运行以下命令即可设置NFS根目录：

sudo tar -xavf /path/to/output_dir/rootfs.tar -C / path / to / nfs_root_dir
请记住添加此路径/etc/exports。

然后，您可以从目标执行NFS引导。

13.1.2。Live CD
要构建实时CD映像，请在“ 文件系统映像”菜单中启用ISO映像选项 。请注意，此选项仅适用于x86和x86-64体系结构，以及是否使用Buildroot构建内核。

您可以使用IsoLinux，Grub或Grub 2作为引导加载程序构建实时CD映像，但只有Isolinux支持将此映像用作Live CD和实时USB（通过Build hybrid image选项）。

您可以使用QEMU测试您的实时CD映像：

qemu-system-i386 -cdrom output / images / rootfs.iso9660
或者如果它是混合ISO，则将其用作硬盘驱动器映像：

qemu-system-i386 -hda输出/ images / rootfs.iso9660
它可以很容易地闪存到USB驱动器dd：

dd if = output / images / rootfs.iso9660 of = / dev / sdb
13.2。chroot环境
如果你想在生成的图像中chroot，那么你应该注意的事情很少：

你应该从tar根文件系统映像设置新的root ;
所选目标体系结构与主机兼容，或者您​​应该使用某些qemu-*二进制文件并在binfmt属性中正确设置它以便能够运行在主机上为目标构建的二进制文件;
Buildroot目前不提供host-qemu并binfmt 正确构建和设置这种用途。
第三部分。开发者指南
第14章Buildroot的工作原理
如上所述，Buildroot基本上是一组Makefiles，可以使用正确的选项下载，配置和编译软件。它还包括各种软件包补丁-主要参与的交叉编译工具链的那些（gcc，binutils和 uClibc）。

每个软件包基本上有一个Makefile，它们以.mk扩展名命名。Makefile分为许多不同的部分。

该toolchain/目录包含Makefile文件和相关文件的有关交叉编译工具链的所有软件：binutils，gcc，gdb， kernel-headers和uClibc。
该arch/目录包含Buildroot支持的所有处理器体系结构的定义。
该package/目录包含所有用户空间工具和库的Makefile和相关文件，Buildroot可以编译并添加到目标根文件系统。每个包有一个子目录。
该linux/目录包含Linux内核的Makefile和相关文件。
该boot/目录包含Buildroot支持的引导加载程序的Makefile和关联文件。
该system/目录包含对系统集成的支持，例如目标文件系统框架和init系统的选择。
该fs/目录包含与生成目标根文件系统映像相关的软件的Makefile和关联文件。
每个目录至少包含2个文件：

something.mk是下载，配置，编译和安装包的Makefile something。
Config.in是配置工具描述文件的一部分。它描述了与包相关的选项。
主Makefile执行以下步骤（配置完成后）：

创建所有的输出目录：staging，target，build等在输出目录（output/默认情况下，可以通过使用指定的另一个值O=）
生成工具链目标。使用内部工具链时，这意味着生成交叉编译工具链。使用外部工具链时，这意味着检查外部工具链的功能并将其导入Buildroot环境。
生成TARGETS变量中列出的所有目标。此变量由所有单个组件的Makefile填充。生成这些目标将触发用户空间包（库，程序），内核，引导加载程序的编译以及根文件系统映像的生成，具体取决于配置。
第15章编码风格
总的来说，这些编码样式规则可以帮助您在Buildroot中添加新文件或重构现有文件。

如果稍微修改一些现有文件，重要的是保持整个文件的一致性，这样你就可以：

要么遵循此文件中使用的可能已弃用的编码样式，
或者完全重做它以使其符合这些规则。
15.1。 Config.in文件
Config.in 文件包含几乎可在Buildroot中配置的任何内容的条目。

条目具有以下模式：

config BR2_PACKAGE_LIBFOO
bool“libfoo”
取决于BR2_PACKAGE_LIBBAZ
选择BR2_PACKAGE_LIBBAR
救命
这是解释libfoo是什么的注释。帮助文本
应该被包裹。

      http://foosoftware.org/libfoo/

的bool，depends on，select和help行缩进与一个选项卡。
帮助文本本身应缩进一个选项卡和两个空格。
应将帮助文本包装为72列，其中制表符为8，因此文本本身为62个字符。
这些Config.in文件是Buildroot中使用的配置工具的输入，这是常规的Kconfig。有关Kconfig语言的更多详细信息，请参阅 http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt。

15.2。该.mk文件
标题：文件以标题开头。它包含模块名称，最好是小写，封装在由80个哈希组成的分隔符之间。标题后必填空白行：

################################################## ##############################
＃
#libfoo
＃
################################################## ##############################
作业：使用=前后一个空格：

LIBFOO_VERSION = 1.0
LIBFOO_CONF_OPTS + = --without-python-support
不要对齐=标志。

缩进：仅使用制表符：

定义LIBFOO_REMOVE_DOC
$（RM）-fr $（TARGET_DIR）/ usr / share / libfoo / doc
$（TARGET_DIR）在/ usr / share / man中/ man3 / libfoo的*
endef
请注意，define块内的命令应始终以制表符开头，因此make会将它们识别为命令。

可选依赖：

喜欢多行语法。

是：

ifeq（$（BR2_PACKAGE_PYTHON），y）
LIBFOO_CONF_OPTS + = --with-python-support
LIBFOO_DEPENDENCIES + = python
其他
LIBFOO_CONF_OPTS + = --without-python-support
万一
没有：

LIBFOO_CONF_OPTS + = --with $（如果$（BR2_PACKAGE_PYTHON）, out）-python-support
LIBFOO_DEPENDENCIES + = $（如果$（BR2_PACKAGE_PYTHON），python，）
保持配置选项和依赖关系紧密相连。
可选的钩子：在一个if块中保持钩子定义和赋值。

是：

ifneq（$（BR2_LIBFOO_INSTALL_DATA），y）
定义LIBFOO_REMOVE_DATA
$（RM）-fr $（TARGET_DIR）/ usr / share / libfoo / data
endef
LIBFOO_POST_INSTALL_TARGET_HOOKS + = LIBFOO_REMOVE_DATA
万一
没有：

定义LIBFOO_REMOVE_DATA
$（RM）-fr $（TARGET_DIR）/ usr / share / libfoo / data
endef

ifneq（$（BR2_LIBFOO_INSTALL_DATA），y）
LIBFOO_POST_INSTALL_TARGET_HOOKS + = LIBFOO_REMOVE_DATA
万一
15.3。文档
该文档使用 asciidoc格式。

有关asciidoc 语法的更多详细信息，请参阅http://www.methods.co.nz/asciidoc/userguide.html。

15.4。支持脚本
support/和utils/目录中的一些脚本是用Python编写的，应遵循 PEP8样式指南的Python代码。

第16章。添加对特定板的支持
Buildroot包含几个公共可用硬件板的基本配置，因此这种板的用户可以轻松构建已知可工作的系统。欢迎您将其他主板的支持添加到Buildroot。

为此，您需要创建一个正常的Buildroot配置，为硬件构建一个基本系统：工具链，内核，引导加载程序，文件系统和一个简单的仅限BusyBox的用户空间。不应该选择特定的包：配置应该尽可能小，并且应该只为目标平台构建一个工作的基本BusyBox系统。您当然可以为内部项目使用更复杂的配置，但Buildroot项目只会集成基本的板配置。这是因为包选择是高度特定于应用程序的。

获得已知的工作配置后，运行make savedefconfig。这将defconfig在Buildroot源代码树的根目录下生成一个最小文件。将此文件移动到configs/ 目录中，然后重命名_defconfig。

建议尽可能使用Linux内核和引导加载程序的上游版本，并尽可能使用默认的内核和引导加载程序配置。如果它们对您的电路板不正确，或者没有默认存在，我们建议您将修复程序发送到相应的上游项目。

但是，与此同时，您可能希望存储特定于目标平台的内核或引导加载程序配置或修补程序。为此，请创建目录board/和子目录 board//。然后，您可以将修补程序和配置存储在这些目录中，并从主Buildroot配置中引用它们。有关更多详细信息，请参阅第9章，项目特定的自定义。

第17章向Buildroot添加新包
本节介绍如何将新包（用户空间库或应用程序）集成到Buildroot中。它还显示了如何集成现有软件包，这是修复问题或调整其配置所必需的。

添加新软件包时，请务必在各种条件下进行测试（请参见第17.23.3节“如何测试软件包”）并检查其编码样式（请参见 第17.23.2节“如何检查编码风格“）。

17.1。包目录
首先package，例如，在软件目录下创建一个目录libfoo。

某些包已按主题分组在子目录中： x11r7，qt5和gstreamer。如果您的软件包符合其中一个类别，请在这些类别中创建软件包目录。但是，不建议使用新的子目录。

17.2。配置文件
要在配置工具中显示包，您需要在包目录中创建一个Config文件。有两种类型： Config.in和Config.in.host。

17.2.1。 Config.in文件
对于目标上使用的包，请创建一个名为的文件Config.in。此文件将包含与我们的libfoo软件相关的选项说明，这些选项将在配置工具中使用和显示。它应该基本上包含：

config BR2_PACKAGE_LIBFOO
bool“libfoo”
救命
这是解释libfoo是什么的注释。帮助文本
应该被包裹。

      http://foosoftware.org/libfoo/

有关配置选项的bool行，help行和其他元数据信息必须使用一个选项卡缩进。帮助文本本身应缩进一个选项卡和两个空格，行应包装以适合72列，其中选项卡为8，因此文本本身为62个字符。帮助文本必须在空行后提及项目的上游URL。

作为Buildroot特有的约定，属性的顺序如下：

选项类型：bool，string…带提示符
如果需要，default价值
depends on表单的 任何依赖
select表单的 任何依赖
帮助关键字和帮助文字。
您可以在if BR2_PACKAGE_LIBFOO…endif 语句中添加其他子选项以配置软件中的特定内容。您可以查看其他包中的示例。该Config.in文件的语法与内核Kconfig文件的语法相同。有关此语法的文档，请访问http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt

最后，你有你的新添加libfoo/Config.in到 package/Config.in（或类别中的子目录，如果你决定把你的包在现有的类别之一）。该文件包含有字母顺序排序按类别和被不 应该包含什么，但裸包的名称。

源“package / libfoo / Config.in”
17.2.2。 Config.in.host文件
还需要为主机系统构建一些软件包。这里有两个选项：

主机包仅需要满足一个或多个目标包的构建时依赖性。在这种情况下，添加 host-foo到目标包的BAR_DEPENDENCIES变量。不Config.in.host应该创建任何 文件。
用户可以从配置菜单中明确选择主机包。在这种情况下，Config.in.host为该主机包创建一个文件：

config BR2_PACKAGE_HOST_FOO
布尔“主人foo”
救命
这是一个解释主机foo的注释。

      http://foosoftware.org/foo/

与Config.in文件相同的编码样式和选项有效。

最后你必须添加新libfoo/Config.in.host的 package/Config.in.host。该文件包含有字母顺序排序 ，并且不应该包含什么，但裸包的名称。

源“package / foo / Config.in.host”
然后可以从Host utilities菜单中获得主机包。

17.2.3。选择depends on或select
Config.in程序包的文件还必须确保启用了依赖项。通常，Buildroot使用以下规则：

select对库的依赖 使用一种依赖关系。这些依赖关系通常不明显，因此让kconfig系统确保选择依赖关系是有意义的。例如，libgtk2包用于 select BR2_PACKAGE_LIBGLIB2确保此库也已启用。该select关键字表示带有后语义的依赖。
depends on当用户确实需要了解依赖关系时， 请使用一种依赖关系。通常，Buildroot使用此类依赖关系来依赖目标体系结构，MMU支持和工具链选项（请参见第17.2.4节“目标和工具链选项的依赖关系”），或依赖于“大”事物，例如X.组织系统。该depends on关键字与表达的正向语义的依赖。
注意。 kconfig语言的当前问题是这两个依赖语义没有内部链接。因此，可以选择不满足其依赖性/要求之一的包。

一个例子示出了两个用法select和depends on。

config BR2_PACKAGE_RRDTOOL
布尔“rrdtool”
取决于BR2_USE_WCHAR
选择BR2_PACKAGE_FREETYPE
选择BR2_PACKAGE_LIBART
选择BR2_PACKAGE_LIBPNG
选择BR2_PACKAGE_ZLIB
救命
RRDtool是OpenSource行业标准，性能卓越
时间序列数据的数据记录和图形系统。

      http://oss.oetiker.ch/rrdtool/

评论“rrdtool需要一个工具链w / wchar”
取决于！BR2_USE_WCHAR
请注意，这两种依赖关系类型只能传递相同类型的依赖关系。

这意味着，在以下示例中：

config BR2_PACKAGE_A
布尔“包A”

config BR2_PACKAGE_B
布尔“包B”
取决于BR2_PACKAGE_A

config BR2_PACKAGE_C
布尔“包C”
取决于BR2_PACKAGE_B

config BR2_PACKAGE_D
布尔“包D”
选择BR2_PACKAGE_B

config BR2_PACKAGE_E
布尔“包E”
选择BR2_PACKAGE_D
Package C如果Package B已选择，则 选择将是可见的，只有Package A在选择后才会显示。
选择Package E将选择Package D，将选择 Package B，它将不检查依赖性Package B，因此它不会选择Package A。
由于Package B被选中但Package A未被选中，这违反了Package Bon 的依赖性Package A。因此，在这种情况下，必须明确添加传递依赖：
config BR2_PACKAGE_D
布尔“包D”
选择BR2_PACKAGE_B
取决于BR2_PACKAGE_A

config BR2_PACKAGE_E
布尔“包E”
选择BR2_PACKAGE_D
取决于BR2_PACKAGE_A
总的来说，对于包库依赖，select应该是首选。

请注意，此类依赖项将确保还启用了依赖项选项，但不一定在您的包之前构建。为此，还需要.mk在包的文件中表示依赖性。

进一步的格式化细节：请参见编码样式 第15.1节“ Config.in文件”。

17.2.4。对目标和工具链选项的依赖性
许多软件包依赖于工具链的某些选项：C库的选择，C ++支持，线程支持，RPC支持，wchar支持或动态库支持。某些软件包只能在某些目标体系结构上构建，或者如果处理器中有MMU可用。

这些依赖关系必须使用相应的依赖于 Config.in文件中的语句来表示。此外，对于工具链选项的依赖性，comment应在未启用该选项时显示a ，以便用户知道该包不可用的原因。不应在注释中显示对目标体系结构或MMU支持的依赖性：由于用户不太可能自由选择其他目标，因此显式显示这些依赖关系毫无意义。

该comment只应是可见的，如果config当工具链的选择相关性得以满足选项本身将是可见的。这意味着必须在comment定义上重复包的所有其他依赖项（包括对目标体系结构和MMU支持的依赖性） 。为了清楚depends on起见，这些非工具链选项的depends on 声明应与工具链选项的声明分开。如果在同一个文件（通常是主程序包）中存在对配置选项的依赖，则最好使用全局if … endif 构造而不是depends on在注释和其他配置选项上重复该语句。

comment包foo 的依赖关系的一般格式是：

foo需要一个带有featA，featB，featC的工具链
例如：

mpd需要一个带有C ++，线程，wchar的工具链
要么

crda需要一个带线程的工具链
请注意，此文本是故意保留的，因此它适合80个字符的终端。

本节的其余部分将枚举不同的目标和工具链选项，要依赖的相应配置符号以及要在注释中使用的文本。

目标架构

依赖符号：BR2_powerpc, BR2_mips…（见arch/Config.in）
注释字符串：无需添加注释
MMU支持

依赖符号： BR2_USE_MMU
注释字符串：无需添加注释
_sync*用于原子操作的 Gcc 内置函数。它们有1种字节，2字节，4字节和8字节的变体。由于不同的体系结构支持不同大小的原子操作，因此每个大小都有一个依赖性符号：

依赖符号：BR2_TOOLCHAIN_HAS_SYNC_11个字节， BR2_TOOLCHAIN_HAS_SYNC_22个字节， BR2_TOOLCHAIN_HAS_SYNC_44个字节，BR2_TOOLCHAIN_HAS_SYNC_8 8个字节。
注释字符串：无需添加注释
_atomic*用于原子操作的 Gcc 内置函数。

依赖符号：BR2_TOOLCHAIN_HAS_ATOMIC。
注释字符串：无需添加注释
内核头文件

依赖符号：BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y，（替换 X_Y为正确的版本，请参阅toolchain/Config.in）
注释字符串：headers >= X.Y和/或headers <= X.Y（替换 X.Y为正确的版本）
GCC版本

依赖符号：BR2_TOOLCHAIN_GCC_AT_LEAST_X_Y，（替换 X_Y为正确的版本，请参阅toolchain/Config.in）
注释字符串：gcc >= X.Y和/或gcc <= X.Y（替换 X.Y为正确的版本）
主机GCC版本

依赖符号：BR2_HOST_GCC_AT_LEAST_X_Y，（替换 X_Y为正确的版本，请参阅Config.in）
注释字符串：无需添加注释
请注意，通常不是包本身具有最小主机GCC版本，而是它所依赖的主机包。
C库

依赖符号：BR2_TOOLCHAIN_USES_GLIBC， BR2_TOOLCHAIN_USES_MUSL，BR2_TOOLCHAIN_USES_UCLIBC
注释字符串：对于C库，使用稍微不同的注释文本：foo needs a glibc toolchain，或foo needs a glibc toolchain w/ C++
C ++支持

依赖符号： BR2_INSTALL_LIBSTDCPP
评论字符串： C++
Fortran支持

依赖符号： BR2_TOOLCHAIN_HAS_FORTRAN
评论字符串： fortran
线程支持

依赖符号： BR2_TOOLCHAIN_HAS_THREADS
注释字符串:( threads除非BR2_TOOLCHAIN_HAS_THREADS_NPTL 也需要，在这种情况下，仅指定NPTL就足够了）
NPTL线程支持

依赖符号： BR2_TOOLCHAIN_HAS_THREADS_NPTL
评论字符串： NPTL
RPC支持

依赖符号： BR2_TOOLCHAIN_HAS_NATIVE_RPC
评论字符串： RPC
wchar支持

依赖符号： BR2_USE_WCHAR
评论字符串： wchar
动态库

依赖符号： !BR2_STATIC_LIBS
评论字符串： dynamic library
17.2.5。依赖于buildroot构建的Linux内核
有些软件包需要一个由buildroot构建的Linux内核。这些通常是内核模块或固件。应在Config.in文件中添加注释以表示此依赖关系，类似于对工具链选项的依赖关系。一般格式是：

foo需要构建一个Linux内核
如果对工具链选项和Linux内核都存在依赖关系，请使用以下格式：

foo需要一个带有featA，featB，featC和Linux内核的工具链
17.2.6。对udev / dev管理的依赖
如果包需要udev / dev管理，它应该依赖于符号 BR2_PACKAGE_HAS_UDEV，并且应该添加以下注释：

foo需要udev / dev管理
如果对工具链选项和udev / dev管理都存在依赖关系，请使用以下格式：

foo需要udev / dev管理和一个带有featA，featB，featC的工具链
17.2.7。对虚拟包提供的功能的依赖性
某些功能可以由多个包提供，例如openGL库。

有关虚拟包的更多信息，请参见第17.11节“虚拟包的基础结构”。

17.3。该.mk文件
最后，这是最难的部分。创建一个名为的文件libfoo.mk。它描述了如何下载，配置，构建，安装包等。

根据包类型，.mk必须使用不同的基础结构以不同的方式编写文件：

用于通用包的Makefile（不使用autotools或CMake）：这些基于类似于基于autotools的包的基础结构，但需要开发人员多做一些工作。它们指定了对程序包的配置，编译和安装应该做什么。必须将此基础结构用于所有不使用autotools作为其构建系统的程序包。将来，可能会为其他构建系统编写其他专用基础结构。我们通过教程 第17.5.1节“ generic-package教程”和 参考 第17.5.2节“ generic-package参考”来介绍它们。
基于autotools的软件的makefile（autoconf，automake等）：我们为这样的软件包提供专用的基础架构，因为autotools是一个非常常见的构建系统。此基础结构必须 用于依赖autotools作为其构建系统的新软件包。我们通过教程 第17.6.1节“ autotools-package教程” 和参考 第17.6.2节“ autotools-package参考”来介绍它们。
基于cmake的软件的Makefile：我们为这样的软件包提供专用的基础架构，因为CMake是一种越来越常用的构建系统，并且具有标准化的行为。此基础结构必须用于依赖CMake的新包。我们通过教程 第17.7.1节“ cmake-package教程” 和参考 第17.7.2节“ cmake-package参考”来介绍它们。
为Python模块的Makefile：我们有使用无论是Python模块的专用基础架构distutils或 setuptools机制。我们通过 教程 第17.8.1节“ python-package教程”和 参考 第17.8.2节“ python-package参考”来介绍它们。
Lua模块的Makefile：我们通过LuaRocks网站提供Lua模块的专用基础设施。我们通过教程 第17.9.1节“ luarocks-package教程”和 参考 第17.9.2节“ luarocks-package参考”来介绍它们。
进一步的格式化细节：参见编写规则 第15.2节“ .mk文件”。

17.4。该.hash文件
如果可能，您必须添加名为的第三个文件，libfoo.hash该文件包含该libfoo 软件包的下载文件的哈希值。不添加.hash文件的唯一原因是由于程序包的下载方式而无法进行哈希检查。

存储在该文件中的哈希用于验证下载文件和许可证文件的完整性。

此文件的格式是每个文件的一行，用于检查散列，每行以空格分隔，具有以下三个字段：

哈希的类型，其中之一：

md5，sha1，sha224，sha256，sha384，sha512，none
文件的哈希：

对于none，一个或多个非空间字符，通常只是字符串xxx
for md5，32个十六进制字符
for sha1，40个十六进制字符
for sha224，56个十六进制字符
for sha256，64个十六进制字符
for sha384，96个十六进制字符
for sha512，128个十六进制字符
文件名：

对于源存档：文件的基本名称，没有任何目录组件，
对于许可证文件：显示的路径FOO_LICENSE_FILES。
以#符号开头的行被视为注释，并被忽略。空行被忽略。

单个文件可以有多个哈希，每个哈希都在自己的行上。在这种情况下，所有哈希必须匹配。

注意。 理想情况下，存储在此文件中的哈希值应与上游发布的哈希值匹配，例如在其网站上，在电子邮件通知中…如果上游提供多种类型的哈希值（例如sha1和sha512），则最好添加所有这些哈希值.hash文件中的哈希值。如果上游没有提供任何哈希，或者只提供md5哈希，那么自己计算至少一个强哈希（最好sha256是但不是md5），并在哈希上方的注释行中提及。

注意。 许可证文件的哈希值用于在包版本发生碰撞时检测许可证更改。在make legal-info目标运行期间检查哈希。对于具有多个版本的程序包（如Qt5），请在该程序包的子目录中创建哈希文件（另请参见第18.2节“如何应用修补程序”）。

注意。 空格的数量无关紧要，因此可以使用空格（或制表符）来正确对齐不同的字段。

该none散列类型保留从存储库下载，就像这些档案git的克隆，一个颠覆结帐 …

下面的示例定义了sha1一个sha256由上游发布的主要libfoo-1.2.3.tar.bz2tarball，一个md5来自上游和一个本地计算sha256的二进制blob哈希，sha256一个下载的补丁，以及一个没有哈希的存档：

#Hashes来自：http：//www.foosoftware.org/download/libfoo-1.2.3.tar.bz2.{sha1,sha256}：
sha1 486fb55c3efa71148fe07895fd713ea3a5ae343a libfoo-1.2.3.tar.bz2
sha256 efc8103cc3bcb06bda6a781532d12701eb081ad83e8f90004b39ab81b65d4369 libfoo-1.2.3.tar.bz2

＃md5来自：http：//www.foosoftware.org/download/libfoo-1.2.3.tar.bz2.md5,sha256本地计算：
md5 2d608f3c318c6b7557d551a5a09314f034​​52f1a1 libfoo-data.bin
sha256 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b libfoo-data.bin

＃本地计算：
sha256 ff52101fb90bbfc3fe9475e425688c660f46216d7e751c4bbdb1dc85cdccacb9 libfoo-fix-blabla.patch

＃1234没有哈希：
none xxx libfoo-1234.tar.gz

＃许可证文件的哈希：
sha256 a45a845012742796534f7e91fe623262ccfb99460a2bd04015bd28d66fba95b8复制
sha256 01b1f9f2c8ee648a7a596a1abe8aa4ed7899b1c9e5551bda06da6e422b04aa55 doc / COPYING.LGPL
如果.hash文件存在，并且它包含下载文件的一个或多个哈希值，则Buildroot计算的哈希值（下载后）必须与存储在.hash文件中的哈希值匹配。如果一个或多个哈希值不匹配，Buildroot会将此视为错误，删除下载的文件并中止。

如果该.hash文件存在，但它不包含下载文件的哈希值，则Buildroot会将此视为错误并中止。但是，下载的文件保留在下载目录中，因为这通常表示.hash文件错误但下载的文件可能正常。

哈希当前检查从http / ftp服务器，Git存储库，使用scp和本地文件复制的文件中获取的文件。不检查其他版本控制系统（例如Subversion，CVS等）的哈希值，因为当从此类版本控制系统获取源代码时，Buildroot当前不会生成可重现的tarball。

只应在.hash保证稳定的文件的文件中添加哈希值。例如，Github自动生成的补丁不能保证稳定，因此它们的哈希值会随着时间的推移而变化。不应下载此类修补程序，而是将其本地添加到包文件夹中。

如果.hash文件丢失，则根本不进行检查。

17.5。具有特定构建系统的包的基础结构
通过与特定的构建系统的软件包，我们指所有那些构建系统不符合标准的，比如一个包 自动工具或CMake的。这通常包括其构建系统基于手写的Makefile或shell脚本的包。

17.5.1。 generic-package教程
01：################################################# ################################
02：＃
03：#libfoo
04：＃
05：################################################## ################################
06：
07：LIBFOO_VERSION = 1.0
08：LIBFOO_SOURCE = libfoo - $（LIBFO{O}_{V}ERSION）.tar.gz09：LIBFO{O}_{S}ITE=http://www.foosoftware.org/download10：LIBFO{O}_{L}ICENSE=GPL-3.0+11：LIBFO{O}_{L}ICENS{E}_{F}ILES=正在复制12：LIBFO{O}_{I}NSTAL{L}_{S}TAGING=YES13：LIBFO{O}_{C}ONFI{G}_{S}CRIPTS=libfoo-config14：LIBFO{O}_{D}EPENDENCIES=host-libaaalibbbb15：16：定义LIBFO{O}_{B}UIL{D}_{C}MDS17：$（MAKE）$（TARGET_CONFIGURE_OPTS）-C $（@D）全部18：恩赐19：20：定义LIBFO{O}_{I}NSTAL{L}_{S}TAGIN{G}_{C}MDS21：$（INSTALL）-D -m 0755 $（@ D）/libfoo.a $（STAGIN{G}_{D}IR）/usr/lib/libfoo.a22：$（INSTALL）-D -m 0644 $（@ D）/foo.h $（STAGIN{G}_{D}IR）/usr/include/foo.h23：$（INSTALL）-D -m 0755 $（@ D）/libfoo.so* $（STAGIN{G}_{D}IR）/usr/lib24：恩赐25：26：定义LIBFO{O}_{I}NSTAL{L}_{T}ARGE{T}_{C}MDS27：$（INSTALL）-D -m 0755 $（@ D）/libfoo.so* $（TARGE{T}_{D}IR）/usr/lib28：$（安装）-d -m 0755 $（TARGE{T}_{D}IR）/etc/foo.d29：恩赐30：31：定义LIBFO{O}_{U}SERS32：foo-1libfoo-1\ast ---LibFoo守护进程33：恩赐34：35：定义LIBFO{O}_{D}EVICES36：/dev/fooc66600420---37：恩赐38：39：定义LIBFO{O}_{P}ERMISSIONS40：/bin/foof4755foolibfoo-----41：恩赐42：43：$（eval $（generic-package））
Makefile从第7行到第11行开始，包含元数据信息：package（LIBFOO_VERSION）的版本，包含package（）的tarball的名称LIBFOO_SOURCE（推荐使用xz-ed tarball）可以从中下载tarball的Internet位置（LIBFOO_SITE） ，license（LIBFOO_LICENSE）和带有许可证文本的文件（LIBFOO_LICENSE_FILES）。LIBFOO_在这种情况下，所有变量必须以相同的前缀开头。此前缀始终是包名称的大写版本（请参阅下文以了解包名称的定义位置）。

在第12行，我们指定此包想要在登台空间安装一些东西。这通常是库所必需的，因为它们必须在暂存空间中安装头文件和其他开发文件。这将确保LIBFOO_INSTALL_STAGING_CMDS执行变量中列出的命令 。

在第13行，我们指定对阶段期间安装的某些libfoo-config文件 进行一些修复LIBFOO_INSTALL_STAGING_CMDS。这些* -config文件是可执行的shell脚本文件，位于$（STAGING_DIR）/ usr / bin目录中，由其他第三方程序包执行，以找出此特定程序包的位置和链接标志。

问题是默认情况下所有这些* -config文件都会给出错误的主机系统链接标志，这些标志不适合交叉编译。

例如： -I / usr / include而不是-I $（STAGING_DIR）/ usr / include 或： -L / usr / lib而不是-L $（STAGING_DIR）/ usr / lib

因此，对这些脚本执行了一些sed魔术，以使它们提供正确的标志。要赋予的参数LIBFOO_CONFIG_SCRIPTS是需要修复的shell脚本的文件名。所有这些名称都与 $（STAGING_DIR）/ usr / bin相关，如果需要，可以给出多个名称。

此外，LIBFOO_CONFIG_SCRIPTS从中删除列出的脚本$(TARGET_DIR)/usr/bin，因为目标上不需要它们。

例17.1。配置脚本：神圣包

package divine安装shell脚本$（STAGING_DIR）/ usr / bin / divine-config。

所以它的修复方法是：

DIVINE_CONFIG_SCRIPTS = divine-config

例17.2。配置脚本：imagemagick包：

包imagemagick安装以下脚本： $（STAGING_DIR）/ usr / bin / {Magick，Magick ++，MagickCore，MagickWand，Wand} -config

所以它的修复方法是：

IMAGEMAGICK_CONFIG_SCRIPTS =
Magick-config Magick ++ - config
MagickCore-config MagickWand-config Wand-config

在第14行，我们指定了此程序包所依赖的依赖项列表。这些依赖项按小写包名称列出，可以是目标包（不带host- 前缀）或主机包（带host-前缀）。Buildroot将确保在当前程序包开始配置之前构建和安装所有这些程序 包。

Makefile的其余部分，第16…29行，定义了在包配置，编译和安装的不同步骤应该做什么。 LIBFOO_BUILD_CMDS告诉我们应该执行哪些步骤来构建包。LIBFOO_INSTALL_STAGING_CMDS告诉应该执行哪些步骤来在暂存空间中安装包。 LIBFOO_INSTALL_TARGET_CMDS告诉我们应该执行哪些步骤来在目标空间中安装软件包。

所有这些步骤都依赖于$(@D)变量，该变量包含已提取包源代码的目录。

在第31…43行，我们定义了这个包使用的用户（例如，将守护进程作为非root用户运行）（LIBFOO_USERS）。

在35…37行，我们定义了这个包（LIBFOO_DEVICES）使用的设备节点文件。

在第39…41行，我们定义了设置为此包安装的特定文件的权限（LIBFOO_PERMISSIONS）。

最后，在第43行，我们调用该generic-package函数，该函数根据前面定义的变量生成使包运行所需的所有Makefile代码。

17.5.2。 generic-package参考
通用目标有两种变体。该generic-package宏用于为目标交叉编译的包。该 host-generic-package宏用于主机包，本机为主机编译。可以在一个.mk 文件中调用它们：一次创建规则以生成目标包，一次创建规则以生成主机包：

$（eval $（generic-package））
$（eval $（host-generic-package））
如果目标程序包的编译需要在主机上安装某些工具，这可能很有用。如果包名是 libfoo，则目标libfoo的包的名称也是 ，而主机的包的名称是 host-libfoo。这些名称应该在其他包的DEPENDENCIES变量中使用，如果它们依赖于libfoo或 host-libfoo。

在所有变量定义之后，对generic-package和/或host-generic-package宏 的调用必须位于.mk文件的末尾。呼叫host-generic-package 必须在呼叫之后 generic-package，如果有的话。

对于目标包，generic-package使用.mk文件定义的变量，并以大写的包名称为前缀： LIBFOO_*。host-generic-package使用HOST_LIBFOO_*变量。对于 某些变量，如果HOST_LIBFOO_前缀变量不存在，则包基础结构使用前缀为的相应变量LIBFOO_。这是针对目标和主机包可能具有相同值的变量完成的。请参阅下文了解详情。

可以在.mk文件中设置以提供元数据信息的变量列表是（假设包名称为libfoo）：

LIBFOO_VERSION，必需，必须包含包的版本。请注意，如果HOST_LIBFOO_VERSION不存在，则假定它与…相同LIBFOO_VERSION。它也可以是修订版号或直接从其版本控制系统获取的包的标记。例子：

发布tarball的版本： LIBFOO_VERSION = 0.1.2
一个git树的sha1： LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057
一个git树的标签 LIBFOO_VERSION = v0.1.2

注意： FOO_VERSION不支持使用分支名称，因为它不能并且不能像人们期望的那样工作：

由于本地缓存，Buildroot不会重新获取存储库，因此希望能够关注远程存储库的人会非常惊讶和失望;
因为两个构建永远不能完全同步，并且因为远程存储库可能随时在分支上获得新的提交，所以使用相同的Buildroot树并构建相同配置的两个用户可能获得不同的源，从而使构建不可再现，并且人们会非常惊讶和失望。
LIBFOO_SOURCE可能包含程序包的tarball的名称，Buildroot将使用它来从中下载tarball LIBFOO_SITE。如果HOST_LIBFOO_SOURCE未指定，则默认为LIBFOO_SOURCE。如果未指定，则假定该值为libfoo-$(LIBFO{O}_{V}ERSION).tar.gz。例：LIBFO{O}_{S}OURCE=foobar-$(LIBFOO_VERSION).tar.bz2
LIBFOO_PATCH可能包含一个以空格分隔的补丁文件名列表，Buildroot将下载并应用于包源代码。如果条目包含://，则Buildroot将假定它是完整URL并从该位置下载补丁。否则，Buildroot将假定应该从中下载补丁 LIBFOO_SITE。如果HOST_LIBFOO_PATCH未指定，则默认为LIBFOO_PATCH。请注意，Buildroot中包含的修补程序本身使用不同的机制：*.patchBuildroot内部程序包目录中存在的所有表单 文件将在提取后应用于程序包（请参阅 修补程序包 第18章，修补程序包）。最后，LIBFOO_PATCH变量中列出的补丁之前会应用 存储在Buildroot包目录中的补丁。
LIBFOO_SITE提供包的位置，可以是URL或本地文件系统路径。HTTP，FTP和SCP是支持的URL类型，用于检索包tar包。在这些情况下，不要包含尾部斜杠：Buildroot将根据需要在目录和文件名之间添加它。Git，Subversion，Mercurial和Bazaar是支持的URL类型，用于直接从源代码管理系统检索包。有一个帮助函数可以更容易地从GitHub下载源代码压缩包（有关详细信息，请参见 第17.23.4节“如何从GitHub添加包”）。文件系统路径可用于指定tarball或包含包源代码的目录。看到LIBFOO_SITE_METHOD下面有关检索如何工作的更多细节。请注意，SCP URL应该是格式 scp://[user@]host:filepath，并且该文件路径是相对于用户主目录的，因此您可能希望在路径前面加上绝对路径的斜杠： scp://[user@]host:/absolutepath。如果HOST_LIBFOO_SITE未指定，则默认为 LIBFOO_SITE。例子： LIBFOO_SITE=http://www.libfoosoftware.org/libfoo LIBFOO_SITE=http://svn.xiph.org/trunk/Tremor LIBFOO_SITE=/opt/software/libfoo.tar.gz LIBFOO_SITE=$(TOPDIR)/../src/libfooLIBFO{O}_D{L}_{O}PTS是一个以空格分隔的列表，用于传递给下载程序的其他选项。用于通过服务器端检查用户登录名和密码或使用代理来检索文档。支持所有有效的下载方法LIBFO{O}_{S}IT{E}_{M}ETHOD;有效选项取决于下载方法（请参阅相应下载实用程序的手册页）。LIBFO{O}_{E}XTR{A}_{D}OWNLOADS是一个以空格分隔的Buildroot应下载的其他文件列表。如果条目包含，://那么Buildroot将假定它是一个完整的URL并将使用此URL下载该文件。否则，Buildroot将假定要下载的文件位于LIBFO{O}_{S}ITE。Buildroot不会对这些附加文件做任何事情，除了下载它们：它将取决于包装配方来使用它们$(LIBFOO_DL_DIR)。
LIBFOO_SITE_METHOD确定用于获取或复制包源代码的方法。在许多情况下，Buildroot从内容中猜测方法，LIBFOO_SITE并且设置LIBFOO_SITE_METHOD 是不必要的。如果HOST_LIBFOO_SITE_METHOD未指定，则默认为值LIBFOO_SITE_METHOD。可能的值LIBFOO_SITE_METHOD是：

wget用于tarball的正常FTP / HTTP下载。时默认使用的LIBFOO_SITE开头http://，https://或 ftp://。
scp使用scp通过SSH下载tarball。默认情况下LIBFOO_SITE以开头时使用scp://。
svn用于从Subversion存储库中检索源代码。默认情况下LIBFOO_SITE以开头时使用svn://。当指定 http://Subversion存储库URL时 LIBFOO_SITE，必须指定LIBFOO_SITE_METHOD=svn。Buildroot执行checkout，在下载缓存中保存为tarball; 后续构建使用tarball而不是执行另一个checkout。
cvs用于从CVS存储库中检索源代码。默认情况下LIBFOO_SITE以开头时使用cvs://。下载的源代码与svn方法一样被缓存。假设匿名pserver模式另外明确定义LIBFOO_SITE。这两个 LIBFOO_SITE=cvs://libfoo.net:/cvsroot/libfoo和 LIBFOO_SITE=cvs://:ext:libfoo.net:/cvsroot/libfoo 被接受，在假设前者匿名PSERVER访问模式。 LIBFOO_SITE 必须包含源URL以及远程存储库目录。该模块是包名称。 LIBFOO_VERSION是强制性的，必须是标签，分支或日期（例如“2014-10-20”，“2014-10-20 13:45”，“2014-10-20 13:45 + 01”请参阅“man” cvs“了解更多详情）。
git用于从Git存储库中检索源代码。默认情况下LIBFOO_SITE以开头时使用git://。下载的源代码与svn 方法一样被缓存。
hg用于从Mercurial存储库中检索源代码。一个 必须指定LIBFOO_SITE_METHOD=hg，当LIBFOO_SITE 含有Mercurial库URL。下载的源代码与svn方法一样被缓存。
bzr用于从Bazaar存储库中检索源代码。默认情况下LIBFOO_SITE以开头时使用bzr://。下载的源代码与svn方法一样被缓存。
file对于本地tarball。在LIBFOO_SITE将包tarball指定为本地文件名时，应该使用此方法 。适用于公共或版本控制不可用的软件。
local用于本地源代码目录。在LIBFOO_SITE指定包含包源代码的本地目录路径时，应该使用它。Buildroot将源目录的内容复制到包的构建目录中。请注意，对于local包，不应用任何修补程序。如果您仍需要修补源代码LIBFOO_POST_RSYNC_HOOKS，请参阅 第17.21.1节“使用POST_RSYNC挂钩”。
LIBFOO_GIT_SUBMODULES可以设置为YES使用存储库中的git子模块创建存档。这仅适用于使用git下载的软件包（即何时 LIBFOO_SITE_METHOD=git）。请注意，当它们包含捆绑的库时，我们尽量不使用这样的git子模块，在这种情况下，我们更喜欢使用自己的包中的那些库。
LIBFOO_STRIP_COMPONENTS是tar在提取时必须从文件名中删除的主要组件（目录）的数量。大多数软件包的tarball都有一个名为“ - ”的前导组件，因此Buildroot将–strip-components = 1传递给tar以删除它。对于没有此组件的非标准软件包，或者要剥离多个主要组件的非标准软件包，请将此变量设置为要传递给tar的值。默认值：1。
LIBFOO_EXCLUDES是在提取存档时要排除的以空格分隔的模式列表。该列表中的每个项目都作为tar --exclude选项传递。默认情况下为空。
LIBFOO_DEPENDENCIES列出当前目标包编译所需的依赖项（就包名而言）。保证在当前程序包的配置开始之前编译和安装这些依赖项。以类似的方式，HOST_LIBFOO_DEPENDENCIES列出当前主机包的依赖项。
LIBFOO_EXTRACT_DEPENDENCIES列出了要提取的当前目​​标包所需的依赖项（就包名称而言）。保证在当前包的提取步骤开始之前编译和安装这些依赖项。这仅在包基础结构内部使用，通常不应由包直接使用。
LIBFOO_PATCH_DEPENDENCIES列出要修补的当前程序包所需的依赖项（就程序包名称而言）。保证在修补当前包之前提取和修补这些依赖项。以类似的方式， HOST_LIBFOO_PATCH_DEPENDENCIES列出当前主机包的依赖项。这很少用; 通常，LIBFOO_DEPENDENCIES是你真正想要使用的。
LIBFOO_PROVIDES列出所有虚拟包libfoo是一个实现。请参见第17.11节“虚拟包的基础结构”。
LIBFOO_INSTALL_STAGING可以设置为YES或NO（默认）。如果设置为YES，则LIBFOO_INSTALL_STAGING_CMDS 执行变量中的命令以将程序包安装到临时目录中。
LIBFOO_INSTALL_TARGET可以设置为YES（默认）或NO。如果设置为YES，则LIBFOO_INSTALL_TARGET_CMDS 执行变量中的命令以将程序包安装到目标目录中。
LIBFOO_INSTALL_IMAGES可以设置为YES或NO（默认）。如果设置为YES，则LIBFOO_INSTALL_IMAGES_CMDS 执行变量中的命令以将包安装到images目录中。
LIBFOO_CONFIG_SCRIPTS列出$（STAGIN{G}_{D}IR）/usr/bin中需要一些特殊修复的文件名，以使它们交叉编译友好。可以给出由空格分隔的多个文件名，并且所有文件名都相对于$（STAGING_DIR）/ usr / bin。列表中列出的文件LIBFOO_CONFIG_SCRIPTS也将被删除， $(TARGET_DIR)/usr/bin因为目标上不需要它们。
LIBFOO_DEVICES列出使用静态设备表时由Buildroot创建的设备文件。要使用的语法是makedevs。您可以在第23章Makedev语法文档中找到有关此语法的一些 文档。此变量是可选的。
LIBFOO_PERMISSIONS列出了在构建过程结束时要完成的权限更改。语法再次是makedevs之一。您可以在第23章Makedev语法文档中找到有关此语法的一些文档。此变量是可选的。
LIBFOO_USERS列出要为此程序包创建的用户，如果它安装了您要作为特定用户运行的程序（例如，作为守护程序或作为cron-job）。语法与makedevs的语法类似，并在第24章Makeusers语法文档中进行了描述。此变量是可选的。
LIBFOO_LICENSE定义发布包的许可证（或许可证）。此名称将出现在生成的清单文件中make legal-info。如果许可证出现在SPDX许可证列表中，请使用SPDX短标识符使清单文件统一。否则，请以精确和简洁的方式描述许可证，避免使用含糊不清的名称，例如BSD实际命名一系列许可证。此变量是可选的。如果未定义，unknown将出现在license此包的清单文件的字段中。此变量的预期格式必须符合以下规则：

如果包的不同部分在不同的许可下发布，则comma单独的许可（例如LIBFOO_LICENSE = GPL-2.0+, LGPL-2.1+）。如果在哪个许可证下许可哪个组件之间有明确的区别，则在括号（例如LIBFOO_LICENSE = GPL-2.0+ (programs), LGPL-2.1+ (libraries)）之间用该组件注释许可证。
如果包是双重许可的，则使用or关键字单独许可 （例如LIBFOO_LICENSE = AFL-2.1 or GPL-2.0+）。
LIBFOO_LICENSE_FILES是包tar包中以空格分隔的文件列表，其中包含发布包的许可证。 make legal-info复制目录中的所有这些文件legal-info。有关详细信息，请参阅第12章，法律声明和许可。此变量是可选的。如果未定义，将生成警告以通知您，not saved并将显示在license files此程序包的清单文件的字段中。
LIBFOO_ACTUAL_SOURCE_TARBALL仅适用于其LIBFOO_SITE/ LIBTOO_SOURCEpair指向实际上不包含源代码但是二进制代码的存档的包 。这是一个非常罕见的情况，只知道应用于已编译的外部工具链，但理论上它可能适用于其他包。在这种情况下，通常可以使用实际源代码获得单独的tarball。设置LIBFOO_ACTUAL_SOURCE_TARBALL为实际源代码存档的名称，Buildroot将下载并在您运行make legal-info以收集与法律相关的材料时使用它。请注意，在常规版本中也不会下载此文件make source。
LIBFOO_ACTUAL_SOURCE_SITE提供实际源tarball的位置。默认值为LIBFOO_SITE，因此如果二进制和源存档托管在同一目录中，则无需设置此变量。如果LIBFOO_ACTUAL_SOURCE_TARBALL未设置，则定义没有意义 LIBFOO_ACTUAL_SOURCE_SITE。
LIBFOO_REDISTRIBUTE可以设置为YES（默认）或NO指示是否允许重新分发包源代码。将其设置NO为非开源包：Buildroot在收集时不会保存此包的源代码legal-info。
LIBFOO_FLAT_STACKSIZE定义内置为FLAT二进制格式的应用程序的堆栈大小。NOMMU架构处理器上的应用程序堆栈大小无法在运行时放大。FLAT二进制格式的默认堆栈大小仅为4k字节。如果应用程序消耗更多堆栈，请在此处附加所需数量。
LIBFOO_BIN_ARCH_EXCLUDE是一个以空格分隔的路径列表（相对于目标目录），在检查包是否正确安装交叉编译的二进制文件时要忽略。你很少需要设置这个变量，除非软件包安装的二进制块的默认位置外，/lib/firmware，/usr/lib/firmware，/lib/modules， /usr/lib/modules，和/usr/share，它会自动排除。
定义这些变量的推荐方法是使用以下语法：

LIBFOO_VERSION = 2.32
现在，定义应该在构建过程的不同步骤执行的内容的变量。

LIBFOO_EXTRACT_CMDS列出要提取包的操作。这通常不需要，因为Buildroot会自动处理tarball。但是，如果程序包使用非标准存档格式（如ZIP或RAR文件）或具有非标准组织的tarball，则此变量允许覆盖程序包基础结构默认行为。
LIBFOO_CONFIGURE_CMDS 列出在编译之前配置包的操作。
LIBFOO_BUILD_CMDS 列出了编译包时要执行的操作。
HOST_LIBFOO_INSTALL_CMDS列出了包是主机包时要执行的安装包的操作。包必须将其文件安装到给定的目录中 $(HOS{T}_{D}IR)。应安装所有文件，包括头文件等开发文件，因为其他软件包可能会在此软件包之上编译。LIBFO{O}_{I}NSTAL{L}_{T}ARGE{T}_{C}MDS列出了当程序包是目标程序包时要将程序包安装到目标目录的操作。包必须将其文件安装到给定的目录中$(TARGET_DIR)。只需安装执行程序包所需的文件 。最终确定目标文件系统后，将再次删除头文件，静态库和文档。
LIBFOO_INSTALL_STAGING_CMDS列出了当程序包是目标程序包时要将程序包安装到临时目录的操作。包必须将其文件安装到给定的目录中$(STAGIN{G}_{D}IR)。应安装所有开发文件，因为编译其他软件包可能需要它们。LIBFO{O}_{I}NSTAL{L}_{I}MAGE{S}_{C}MDS列出了当程序包是目标程序包时要将程序包安装到images目录的操作。包必须将其文件安装到给定的目录中$(BINARIES_DIR)。只有那些不属于二进制映像（即图像）的文件TARGET_DIR才能放在这里，这些文件不属于启动电路板。例如，如果包具有类似于内核映像，引导加载程序或根文件系统映像的二进制文件，则应使用此步骤。
LIBFOO_INSTALL_INIT_SYSV并LIBFOO_INSTALL_INIT_SYSTEMD列出为类似systemV的init系统（busybox，sysvinit等）或systemd单元安装init脚本的操作。这些命令仅在安装相关的init系统时运行（即，如果在配置中选择systemd作为init系统，则仅 LIBFOO_INSTALL_INIT_SYSTEMD运行）。
LIBFOO_HELP_CMDS列出要打印包帮助的操作，该操作包含在主make help输出中。这些命令可以以任何格式打印任何内容。这很少使用，因为包很少有自定义规则。除非您确实知道需要打印帮助，否则请勿使用此变量。
定义这些变量的首选方法是：

定义LIBFOO_CONFIGURE_CMDS
行动1
行动2
行动3
endef
在操作定义中，您可以使用以下变量：

$(LIBFOO_PKGDIR)包含包含libfoo.mk和Config.in文件的目录的路径 。当需要安装捆绑在Buildroot中的文件时，此变量很有用，如运行时配置文件，闪屏图像…
$(@D)，其中包含解压缩包源代码的目录。
$(LIBFOO_DL_DIR)包含libfoo存储Buildroot for的所有下载的目录的路径。
$(TARGE{T}_{C}C)，$(TARGET_LD)等来获得目标的交叉编译公用事业
$(TARGE{T}_{C}ROSS)获取交叉编译工具链前缀当然$(HOST_DIR)，$(STAGIN{G}_{D}IR)以及$(TARGET_DIR) 正确安装软件包的变量。
最后，您还可以使用钩子。有关更多信息，请参见第17.21节“各种构建步骤中可用的挂钩”。

17.6。基于autotools的软件包的基础结构
17.6.1。 autotools-package教程
首先，让我们看看如何.mk为基于autotools的包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#libfoo
04：＃
05：################################################## ################################
06：
07：LIBFOO_VERSION = 1.0
08：LIBFOO_SOURCE = libfoo - $（LIBFO{O}_{V}ERSION）.tar.gz09：LIBFO{O}_{S}ITE=http://www.foosoftware.org/download10：LIBFO{O}_{I}NSTAL{L}_{S}TAGING=是11：LIBFO{O}_{I}NSTAL{L}_{T}ARGET=NO12：LIBFO{O}_{C}ON{F}_{O}PTS=--disable-shared13：LIBFO{O}_{D}EPENDENCIES=libglib2host-pkgconf14：15：$（eval $（autotools-package））
在第7行，我们声明了包的版本。

在第8行和第9行，我们声明了tarball的名称（建议使用xz-ed tarball）以及tar上的tarball位置。Buildroot将自动从此位置下载tarball。

在第10行，我们告诉Buildroot将软件包安装到临时目录。登台目录位于output/staging/ 安装所有软件包的目录中，包括其开发文件等。默认情况下，软件包未安装到登台目录，因为通常只需要在登台目录中安装库：需要开发文件来编译其他库或应用程序，具体取决于它们。此外，默认情况下，启用分段安装时，使用该make install命令将软件包安装在此位置。

在第11行，我们告诉Buildroot不要将软件包安装到目标目录。该目录包含将成为目标上运行的根文件系统的内容。对于纯静态库，没有必要将它们安装在目标目录中，因为它们不会在运行时使用。默认情况下，启用目标安装; 几乎不需要将此变量设置为NO。此外，默认情况下，使用该make install命令将软件包安装在此位置。

在第12行，我们告诉Buildroot传递一个自定义配置选项，该选项将./configure在配置和构建包之前传递给脚本。

在第13行，我们声明了我们的依赖项，以便在我们的包的构建过程开始之前构建它们。

最后，在第15行，我们调用autotools-package 生成所有Makefile规则的宏，这些规则实际上允许构建包。

17.6.2。 autotools-package参考
autotools包基础结构的主要宏是 autotools-package。它类似于generic-package宏。使用host-autotools-package宏也可以使用目标和主机包 。

就像通用基础架构一样，autotools基础架构通过在调用autotools-package宏之前定义许多变量来工作 。

首先，所有存在于通用基础架构包的元数据信息的变量也存在于自动工具的基础设施： LIBFOO_VERSION，LIBFOO_SOURCE， LIBFOO_PATCH，LIBFOO_SITE， LIBFOO_SUBDIR，LIBFOO_DEPENDENCIES， LIBFOO_INSTALL_STAGING，LIBFOO_INSTALL_TARGET。

还可以定义一些特定于autotools基础结构的附加变量。其中许多仅在非常特殊的情况下有用，因此典型的包只会使用其中的一些。

LIBFOO_SUBDIR可能包含包含configure脚本的包内的子目录的名称。这很有用，例如，主配置脚本不在tarball提取的树的根目录下。如果HOST_LIBFOO_SUBDIR未指定，则默认为LIBFOO_SUBDIR。
LIBFOO_CONF_ENV，指定要传递给configure脚本的其他环境变量。默认情况下为空。
LIBFOO_CONF_OPTS，指定要传递给配置脚本的其他配置选项。默认情况下为空。
LIBFOO_MAKE，指定备用make 命令。当在配置（使用BR2_JLEVEL）中启用并行make时，这通常很有用，但出于某种原因，应该为给定的包禁用此功能。默认情况下，设置为$(MAKE)。如果包不支持并行构建，则应将其设置为LIBFO{O}_{M}AKE=$(MAKE1)。
LIBFOO_MAKE_ENV，指定要在构建步骤中传递的其他环境变量。这些在make命令之前传递。默认情况下为空。
LIBFOO_MAKE_OPTS，指定要在构建步骤中传递的其他变量。这些是在make命令之后传递的 。默认情况下为空。
LIBFOO_AUTORECONF，告诉是否应该自动配置包（即，是否应该通过重新运行autoconf，automake，libtool等重新生成configure脚本和Makefile.in文件）。有效值为YES和 NO。默认情况下，值为NO
LIBFOO_AUTORECONF_ENV，指定要传递给autoreconf程序的其他环境变量if LIBFOO_AUTORECONF=YES。它们在autoreconf命令的环境中传递。默认情况下为空。
LIBFOO_AUTORECONF_OPTS指定传递给autoreconf程序的其他选项if LIBFOO_AUTORECONF=YES。默认情况下为空。
LIBFOO_GETTEXTIZE，告诉包是否应该被gettextized（即如果包使用与Buildroot提供的不同的gettext版本，并且需要运行 gettextize。）仅在有效时LIBFOO_AUTORECONF=YES。有效值为YES和NO。默认是NO。
LIBFOO_GETTEXTIZE_OPTS，指定传递给gettextize程序的其他选项，如果LIBFOO_GETTEXTIZE=YES。例如，如果.po文件不在标准位置（即位于po/包的根目录中），则可以使用该方法。默认情况下，-f。
LIBFOO_LIBTOOL_PATCH告诉我们是否应该应用修复libtool交叉编译问题的Buildroot补丁。有效值为YES和NO。默认情况下，值为YES
LIBFOO_INSTALL_STAGING_OPTS包含用于将程序包安装到临时目录的make选项。默认情况下，该值为DESTDIR=$(STAGIN{G}_{D}IR)install大多数autotools软件包都是正确的。它仍然可以覆盖它。LIBFO{O}_{I}NSTAL{L}_{T}ARGE{T}_{O}PTS包含用于将程序包安装到目标目录的make选项。默认情况下，值为DESTDIR=$(TARGET_DIR) install。对于大多数autotools软件包，默认值是正确的，但如果需要，仍可以覆盖它。
使用autotools基础结构，已经定义了构建和安装软件包所需的所有步骤，并且它们通常适用于大多数基于autotools的软件包。但是，在需要时，仍然可以自定义在任何特定步骤中执行的操作：

通过添加后操作挂钩（在解压缩，补丁，配置，构建或安装之后）。有关详细信息，请参见第17.21节“各种构建步骤中可用的挂钩”。
通过覆盖其中一个步骤。例如，即使使用了autotools基础结构，如果包.mk文件定义了自己的LIBFOO_CONFIGURE_CMDS变量，也将使用它来代替默认的autotools变量。但是，使用此方法应限于非常具体的情况。在一般情况下不要使用它。
17.7。基于CMake的软件包的基础架构
17.7.1。 cmake-package教程
首先，让我们看看如何.mk为基于CMake的包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#libfoo
04：＃
05：################################################## ################################
06：
07：LIBFOO_VERSION = 1.0
08：LIBFOO_SOURCE = libfoo - $（LIBFO{O}_{V}ERSION）.tar.gz09：LIBFO{O}_{S}ITE=http://www.foosoftware.org/download10：LIBFO{O}_{I}NSTAL{L}_{S}TAGING=是11：LIBFO{O}_{I}NSTAL{L}_{T}ARGET=NO12：LIBFO{O}_{C}ON{F}_{O}PTS=-DBUIL{D}_{D}EMOS=ON13：LIBFO{O}_{D}EPENDENCIES=libglib2host-pkgconf14：15：$（eval $（cmake-package））
在第7行，我们声明了包的版本。

在第8行和第9行，我们声明了tarball的名称（建议使用xz-ed tarball）以及tar上的tarball位置。Buildroot将自动从此位置下载tarball。

在第10行，我们告诉Buildroot将软件包安装到临时目录。登台目录位于output/staging/ 安装所有软件包的目录中，包括其开发文件等。默认情况下，软件包未安装到登台目录，因为通常只需要在登台目录中安装库：需要开发文件来编译其他库或应用程序，具体取决于它们。此外，默认情况下，启用分段安装时，使用该make install命令将软件包安装在此位置。

在第11行，我们告诉Buildroot不要将软件包安装到目标目录。该目录包含将成为目标上运行的根文件系统的内容。对于纯静态库，没有必要将它们安装在目标目录中，因为它们不会在运行时使用。默认情况下，启用目标安装; 几乎不需要将此变量设置为NO。此外，默认情况下，使用该make install命令将软件包安装在此位置。

在第12行，我们告诉Buildroot在配置包时将自定义选项传递给CMake。

在第13行，我们声明了我们的依赖项，以便在我们的包的构建过程开始之前构建它们。

最后，在第15行，我们调用cmake-package 生成所有Makefile规则的宏，这些规则实际上允许构建包。

17.7.2。 cmake-package参考
CMake包基础结构的主要宏是 cmake-package。它类似于generic-package宏。使用host-cmake-package宏也可以使用目标和主机包 。

就像通用基础设施一样，CMake基础设施通过在调用cmake-package 宏之前定义许多变量来工作。

首先，所有存在于通用基础架构包的元数据信息的变量也存在于CMake的基础设施： LIBFOO_VERSION，LIBFOO_SOURCE，LIBFOO_PATCH，LIBFOO_SITE， LIBFOO_SUBDIR，LIBFOO_DEPENDENCIES，LIBFOO_INSTALL_STAGING， LIBFOO_INSTALL_TARGET。

还可以定义一些特定于CMake基础结构的附加变量。其中许多仅在非常特殊的情况下有用，因此典型的包只会使用其中的一些。

LIBFOO_SUBDIR可能包含包含主CMakeLists.txt文件的包内的子目录的名称。这很有用，例如，主CMakeLists.txt文件不在tarball提取的树的根目录下。如果HOST_LIBFOO_SUBDIR未指定，则默认为LIBFOO_SUBDIR。
LIBFOO_CONF_ENV，指定要传递给CMake的其他环境变量。默认情况下为空。
LIBFOO_CONF_OPTS，指定要传递给CMake的其他配置选项。默认情况下为空。许多常见的CMake选项由cmake-package基础设施设置; 所以通常没有必要在包的*.mk文件中设置它们，除非你想要覆盖它们：

CMAKE_BUILD_TYPE是由BR2_ENABLE_DEBUG;
CMAKE_INSTALL_PREFIX;
BUILD_SHARED_LIBS是由BR2_STATIC_LIBS;
BUILD_DOC，BUILD_DOCS被禁用;
BUILD_EXAMPLE，BUILD_EXAMPLES被禁用;
BUILD_TEST，BUILD_TESTS，BUILD_TESTING将被禁用。
LIBFOO_SUPPORTS_IN_SOURCE_BUILD = NO 应该在无法在源代码树内构建软件包但需要单独的构建目录时设置。
LIBFOO_MAKE，指定备用make命令。当在配置（使用BR2_JLEVEL）中启用并行make时，这通常很有用，但出于某种原因，应该为给定的包禁用此功能。默认情况下，设置为 $(MAKE)。如果包不支持并行构建，则应将其设置为LIBFO{O}_{M}AKE=$(MAKE1)。
LIBFOO_MAKE_ENV，指定要在构建步骤中传递的其他环境变量。这些在make 命令之前传递。默认情况下为空。
LIBFOO_MAKE_OPTS，指定要在构建步骤中传递的其他变量。这些是在make命令之后传递的。默认情况下为空。
LIBFOO_INSTALL_STAGING_OPTS包含用于将程序包安装到临时目录的make选项。默认情况下，该值为DESTDIR=$(STAGIN{G}_{D}IR)install大多数CMake软件包正确。它仍然可以覆盖它。LIBFO{O}_{I}NSTAL{L}_{T}ARGE{T}_{O}PTS包含用于将程序包安装到目标目录的make选项。默认情况下，值为DESTDIR=$(TARGET_DIR) install。对于大多数CMake软件包，默认值是正确的，但如果需要，仍然可以覆盖它。
使用CMake基础架构，已经定义了构建和安装软件包所需的所有步骤，并且它们通常适用于大多数基于CMake的软件包。但是，在需要时，仍然可以自定义在任何特定步骤中执行的操作：

通过添加后操作挂钩（在解压缩，补丁，配置，构建或安装之后）。有关详细信息，请参见第17.21节“各种构建步骤中可用的挂钩”。
通过覆盖其中一个步骤。例如，即使使用CMake基础结构，如果包.mk文件定义了自己的 LIBFOO_CONFIGURE_CMDS变量，也将使用它来代替默认的CMake。但是，使用此方法应限于非常具体的情况。在一般情况下不要使用它。
17.8。Python包的基础结构
此基础结构适用于使用标准Python setuptools机制作为其构建系统的Python包，通常可通过setup.py脚本的使用来识别。

17.8.1。 python-package教程
首先，让我们看看如何.mk为Python包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#python-foo
04：＃
05：################################################## ################################
06：
07：PYTHON_FOO_VERSION = 1.0
08：PYTHON_FOO_SOURCE = python-foo - $（PYTHO{N}_{F}O{O}_{V}ERSION）.tar.xz09：PYTHO{N}_{F}O{O}_{S}ITE=http://www.foosoftware.org/download10：PYTHO{N}_{F}O{O}_{L}ICENSE=BSD-3-Clause11：PYTHO{N}_{F}O{O}_{L}ICENS{E}_{F}ILES=许可证12：PYTHO{N}_{F}O{O}_{E}NV=SOM{E}_{V}AR=113：PYTHO{N}_{F}O{O}_{D}EPENDENCIES=libmad14：PYTHO{N}_{F}O{O}_{S}ETU{P}_{T}YPE=distutils15：16：$（eval $（python-package））
在第7行，我们声明了包的版本。

在第8行和第9行，我们声明了tarball的名称（建议使用xz-ed tarball）以及tar上的tarball位置。Buildroot将自动从此位置下载tarball。

在第10行和第11行，我们提供有关包的许可详细信息（第10行的许可证以及第11行的包含许可证文本的文件）。

在第12行，我们告诉Buildroot在setup.py配置包时将自定义选项传递给Python 脚本。

在第13行，我们声明了我们的依赖项，以便在我们的包的构建过程开始之前构建它们。

在第14行，我们声明了正在使用的特定Python构建系统。在这种情况下，使用distutilsPython构建系统。这两个支持的是distutils和setuptools。

最后，在第16行，我们调用python-package生成所有Makefile规则的宏，这些规则实际上允许构建包。

17.8.2。 python-package参考
作为一个策略，仅提供Python模块的包应该全部python-在Buildroot中命名。使用Python构建系统但不是Python模块的其他软件包可以自由选择其名称（Buildroot中的现有示例是scons和 supervisor）。

在他们的Config.in文件中，他们应该依赖于BR2_PACKAGE_PYTHON 这样，当Buildroot为模块启用Python 3时，我们将能够在Python 3上逐步启用Python模块。

Python包基础结构的主要宏是 python-package。它类似于generic-package宏。也可以使用host-python-package宏创建Python主机包 。

就像通用基础结构一样，Python基础结构通过在调用python-package 或host-python-package宏之前定义许多变量来工作。

所有存在于包的元数据信息的变量 通用包基础设施 第17.5.2，“ generic-package参考”也存在于Python的基础设施：PYTHON_FOO_VERSION， PYTHON_FOO_SOURCE，PYTHON_FOO_PATCH，PYTHON_FOO_SITE， PYTHON_FOO_SUBDIR，PYTHON_FOO_DEPENDENCIES，PYTHON_FOO_LICENSE， PYTHON_FOO_LICENSE_FILES，PYTHON_FOO_INSTALL_STAGING，等。

注意：

没有必要添加python或host-python包含 PYTHON_FOO_DEPENDENCIES变量，因为Python包基础结构会根据需要自动添加这些基本依赖项。
类似地，不需要为基于setuptools的包添加host-setuptools和/或 host-distutilscross依赖PYTHON_FOO_DEPENDENCIES，因为这些是由Python基础结构根据需要自动添加的。
必须使用一个特定于Python基础结构的变量：

PYTHON_FOO_SETUP_TYPE，定义包使用哪个Python构建系统。这两个支持的值是distutils和 setuptools。如果您不知道包中使用了哪一个，请查看setup.py包源代码中的文件，看看它是从distutils模块还是从模块 导入的东西setuptools。
可以选择定义一些特定于Python基础结构的附加变量，具体取决于程序包的需要。其中许多仅在非常特殊的情况下有用，因此典型的包只会使用其中的一些，或者不使用。

PYTHON_FOO_ENV，指定要传递给Python setup.py脚本的其他环境变量（对于构建和安装步骤）。请注意，基础结构会自动传递几个标准变量，这些变量在PKG_PYTHON_DISTUTILS_ENV （对于distutils目标包）HOST_PKG_PYTHON_DISTUTILS_ENV （对于distutils主机包）PKG_PYTHON_SETUPTOOLS_ENV（对于setuptools目标包）和HOST_PKG_PYTHON_SETUPTOOLS_ENV （对于setuptools主机包）中定义。
PYTHON_FOO_BUILD_OPTS，指定setup.py在构建步骤中传递给Python 脚本的其他选项。对于目标distutils包，PKG_PYTHON_DISTUTILS_BUILD_OPTS选项已经由基础结构自动传递。
PYTHON_FOO_INSTALL_TARGET_OPTS，PYTHON_FOO_INSTALL_STAGING_OPTS， HOST_PYTHON_FOO_INSTALL_OPTS以指定附加的选项传递给了Python setup.py分别暂存安装步骤或主机安装，在目标安装步骤脚本。请注意，基础结构会自动传递一些选项，这些选项在（PKG_PYTHON_DISTUTILS_INSTALL_TARGET_OPTS 或PKG_PYTHON_DISTUTILS_INSTALL_STAGING_OPTS针对目标distutils包）HOST_PKG_PYTHON_DISTUTILS_INSTALL_OPTS（对于主机distutils包）PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS或 PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS（对于目标setuptools包）和HOST_PKG_PYTHON_SETUPTOOLS_INSTALL_OPTS（对于主机setuptools包）中定义。
HOST_PYTHON_FOO_NEEDS_HOST_PYTHON，定义主机python解释器。此变量的使用仅限于主机包。支持的两个值是python2和python3。它将确保正确的主机python包可用，并将为构建调用它。如果某些构建步骤被重载，则必须在命令中显式调用正确的python解释器。
使用Python基础结构，已经定义了构建和安装软件包所需的所有步骤，并且它们通常适用于大多数基于Python的软件包。但是，在需要时，仍然可以自定义在任何特定步骤中执行的操作：

通过添加后操作挂钩（在解压缩，补丁，配置，构建或安装之后）。有关详细信息，请参见第17.21节“各种构建步骤中可用的挂钩”。
通过覆盖其中一个步骤。例如，即使使用了Python基础结构，如果包.mk文件定义了自己的 PYTHON_FOO_BUILD_CMDS变量，也将使用它而不是默认的Python变量。但是，使用此方法应限于非常具体的情况。在一般情况下不要使用它。
17.8.3。python-package从PyPI存储库生成a
如果PyPI上提供了您要为其创建Buildroot包的Python包，则可能需要使用scanpypi位于其中的工具utils/来自动执行该过程。

您可以在此处找到现有PyPI包的列表 。

scanpypi需要setuptools在主机上安装Python 软件包。

在buildroot目录的根目录下执行：

utils / scanpypi foo bar -o package
这将生成包python-foo，python-bar如果它们存在于https://pypi.python.org上，则生成包文件夹。

找到external python modules菜单并将包裹插入其中。请记住，菜单中的项目应按字母顺序排列。

请记住，您很可能必须手动检查包是否有任何错误，因为生成器无法猜到这些错误（例如，对任何python核心模块的依赖关系，如BR2_PACKAGE_PYTHON_ZLIB）。另请注意，许可证和许可证文件已被猜到，必须进行检查。您还需要手动将包添加到package/Config.in文件中。

如果您的Buildroot包不在官方Buildroot树中但在br2外部树中，请使用-o标志，如下所示：

utils / scanpypi foo bar -o other_package_dir
这将产生包python-foo和python-bar在 other_package_directory来代替package。

选项-h将列出可用选项：

utils / scanpypi -h
17.8.4。 python-packageCFFI后端
C的C外部函数接口（CFFI）提供了一种方便可靠的方法，可以使用C编写的接口声明从Python调用编译的C代码。依赖于此后端的Python包可以通过其文件字段中的cffi依赖项 的外观来识别。install_requiressetup.py

这样的包应该：

添加python-cffi为运行时依赖项，以便在目标上安装已编译的C库包装器。这是通过添加select BR2_PACKAGE_PYTHON_CFFI到包中来实现的 Config.in。
config BR2_PACKAGE_PYTHON_FOO
bool“python-foo”
选择BR2_PACKAGE_PYTHON_CFFI＃runtime
添加host-python-cffi为构建时依赖项以交叉编译C包装器。这是通过添加host-python-cffi到PYTHON_FOO_DEPENDENCIES变量来实现的 。
################################################## ##############################
＃
#python-foo
＃
################################################## ##############################

…

PYTHON_FOO_DEPENDENCIES = host-python-cffi

$（eval $（python-package））
17.9。基于LuaRocks的软件包的基础结构
17.9.1。 luarocks-package教程
首先，让我们看一下如何.mk为基于LuaRocks的包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#lua-foo
04：＃
05：################################################## ################################
06：
07：LUA_FOO_VERSION = 1.0.2-1
08：LUA_FOO_NAME_UPSTREAM = foo
09：LUA_FOO_DEPENDENCIES =吧
10：
11：LUA_FOO_BUILD_OPTS + = BAR_INCDIR = $（STAGING_DIR）/ usr / include
12：LUA_FOO_BUILD_OPTS + = BAR_LIBDIR = $（STAGING_DIR）/ usr / lib
13：LUA_FOO_LICENSE = luaFoo许可证
14：LUA_FOO_LICENSE_FILES = $（LU{A}_{F}O{O}_{S}UBDIR）/复制15：16：$（eval $（luarocks-package））
在第7行，我们声明了包的版本（与rockspec中的相同，它是上游版本和rockspec修订版的串联，用连字符分隔-）。

在第8行，我们声明该包在LuaRocks上被称为“foo”。在Buildroot中，我们为Lua相关的包提供一个以“lua”开头的名称，因此Buildroot名称与上游名称不同。LUA_FOO_NAME_UPSTREAM 在两个名字之间建立联系。

在第9行，我们声明了对本机库的依赖，以便在我们的包的构建过程开始之前构建它们。

在第11-12行，我们告诉Buildroot在构建包时将自定义选项传递给LuaRocks。

在第13-14行，我们指定了包的许可条款。

最后，在第16行，我们调用luarocks-package 生成所有Makefile规则的宏，这些规则实际上允许构建包。

17.9.2。 luarocks-package参考
LuaRocks是Lua模块部署和管理系统，并支持多种build.type：builtin，make和cmake。在Buildroot的上下文中，luarocks-package基础结构仅支持该builtin 模式。使用make或cmake构建机制的LuaRocks包应分别使用Buildroot中的generic-package和cmake-package 基础结构进行打包。

LuaRocks包基础结构的主要宏是luarocks-package：generic-package它通过定义一些变量来提供有关包的元数据信息，然后调用luarocks-package。值得一提的是，不支持为主机构建LuaRocks包，因此host-luarocks-package未实现宏。

就像通用基础架构一样，LuaRocks基础架构通过在调用luarocks-package 宏之前定义许多变量来工作。

首先，所有存在于通用基础架构包的元数据信息的变量也存在于LuaRocks基础设施： LUA_FOO_VERSION，LUA_FOO_SOURCE，LUA_FOO_SITE， LUA_FOO_DEPENDENCIES，LUA_FOO_LICENSE，LUA_FOO_LICENSE_FILES。

其中两个由LuaRocks基础设施填充（用于该 download步骤）。如果您的包未托管在LuaRocks镜像上 $(BR2_LUAROCKS_MIRROR)，则可以覆盖它们：

LUA_FOO_SITE，默认为 $(BR2_LUAROCKS_MIRROR)
LUA_FOO_SOURCE，默认为 $(lowercaseLU{A}_{F}O{O}_{N}AM{E}_{U}PSTREAM)-$(LUA_FOO_VERSION).src.rock
还定义了一些特定于LuaRocks基础结构的附加变量。在特定情况下可以覆盖它们。

LUA_FOO_NAME_UPSTREAM，默认为lua-foo，即Buildroot包名称
LUA_FOO_ROCKSPEC，默认为 $(lowercaseLU{A}_{F}O{O}_{N}AM{E}_{U}PSTREAM)-$(LUA_FOO_VERSION).rockspec
LUA_FOO_SUBDIR，默认为 $(LU{A}_{F}O{O}_{N}AM{E}_{U}PSTREAM)-$(LUA_FOO_VERSION_WITHOUT_ROCKSPEC_REVISION)
LUA_FOO_BUILD_OPTS包含luarocks build调用的其他构建选项 。
17.10。Perl / CPAN包的基础结构
17.10.1。 perl-package教程
首先，让我们看看如何.mk为Perl / CPAN包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#perl-foo-bar
04：＃
05：################################################## ################################
06：
07：PERL_FOO_BAR_VERSION = 0.02
08：PERL_FOO_BAR_SOURCE = Foo-Bar - $（PERL_FOO_BAR_VERSION）.tar.gz
09：PERL_FOO_BAR_SITE = $（BR{2}_{C}PA{N}_{M}IRROR）/authors/id/M/MO/MONGER10：PER{L}_{F}O{O}_{B}A{R}_{D}EPENDENCIES=perl-strictures11：PER{L}_{F}O{O}_{B}A{R}_{L}ICENSE=Artistic或GPL-1.0+12：PER{L}_{F}O{O}_{B}A{R}_{L}ICENS{E}_{F}ILES=许可证13：14：$（eval $（perl-package））
在第7行，我们声明了包的版本。

在第8行和第9行，我们在CPAN服务器上声明tarball的名称和tarball的位置。Buildroot将自动从此位置下载tarball。

在第10行，我们声明了我们的依赖项，以便在我们的包的构建过程开始之前构建它们。

在第11行和第12行，我们提供有关包的许可详细信息（第11行的许可证以及第12行包含许可证文本的文件）。

最后，在第14行，我们调用perl-package生成所有Makefile规则的宏，这些规则实际上允许构建包。

大多数这些数据都可以从https://metacpan.org/中检索到。因此，可以通过utils/scancpan Foo-Bar在Buildroot目录（或br2外部树）中运行脚本来生成此文件和Config.in 。此脚本为请求的包创建Config.in文件和foo-bar.mk文件，并为CPAN指定的所有依赖项创建递归。您仍应手动编辑结果。特别是，应检查以下事项。

如果perl模块链接到另一个（非perl）包提供的共享库，则不会自动添加此依赖项。它必须手动添加到PERL_FOO_BAR_DEPENDENCIES。
package/Config.in必须手动更新 该文件以包含生成的Config.in文件。作为提示，scancpan脚本打印出所需的source "…"语句，按字母顺序排序。
17.10.2。 perl-package参考
作为策略，提供Perl / CPAN模块的软件包都应该perl-在Buildroot中命名。

此基础结构处理各种Perl构建系统： ExtUtils-MakeMaker（EUMM），Module-Build（MB）和Module-Build-Tiny。 Build.PL默认情况下，当包提供a Makefile.PL 和a 时，首选Build.PL。

Perl / CPAN包基础结构的主要宏是 perl-package。它类似于generic-package宏。使用host-perl-package宏也可以使用目标和主机包 。

就像通用基础设施一样，Perl / CPAN基础设施通过在调用perl-package宏之前定义许多变量来工作 。

首先，所有存在于通用基础架构包的元数据信息的变量也存在于perl / CPAN基础设施： PERL_FOO_VERSION，PERL_FOO_SOURCE， PERL_FOO_PATCH，PERL_FOO_SITE， PERL_FOO_SUBDIR，PERL_FOO_DEPENDENCIES， PERL_FOO_INSTALL_TARGET。

请注意，除非定义了变量，否则设置PERL_FOO_INSTALL_STAGING为YES无效PERL_FOO_INSTALL_STAGING_CMDS。perl基础结构不定义这些命令，因为Perl模块通常不需要安装到staging目录中。

还可以定义一些特定于Perl / CPAN基础结构的附加变量。其中许多仅在非常特殊的情况下有用，因此典型的包只会使用其中的一些。

PERL_FOO_PREFER_INSTALLER/ HOST_PERL_FOO_PREFER_INSTALLER，指定首选安装方法。可能的值是 EUMM（对于Makefile.PL基于安装的使用 ExtUtils-MakeMaker）和MB（对于Build.PL基于安装的使用Module-Build）。仅当包提供两种安装方法时才使用此变量。
PERL_FOO_CONF_ENV/ HOST_PERL_FOO_CONF_ENV，指定要传递给perl Makefile.PLor的其他环境变量perl Build.PL。默认情况下为空。
PERL_FOO_CONF_OPTS/ HOST_PERL_FOO_CONF_OPTS，指定要传递给perl Makefile.PL或的其他配置选项perl Build.PL。默认情况下为空。
PERL_FOO_BUILD_OPTS/ HOST_PERL_FOO_BUILD_OPTS，指定传递到构建步骤make pure_all或perl Build build在构建步骤中的其他选项。默认情况下为空。
PERL_FOO_INSTALL_TARGET_OPTS，指定要传递到安装步骤make pure_install或perl Build install在安装步骤中的其他选项。默认情况下为空。
HOST_PERL_FOO_INSTALL_OPTS，指定要传递到安装步骤make pure_install或perl Build install在安装步骤中的其他选项。默认情况下为空。
17.11。虚拟包的基础结构
在Buildroot中，虚拟包是一个包，其功能由一个或多个包（称为提供者）提供。虚拟包管理是一种可扩展的机制，允许用户选择rootfs中使用的提供者。

例如，OpenGL ES是嵌入式系统上的2D和3D图形的API。对于Allwinner Tech Sunxi和Texas Instruments OMAP35xx平台，此API的实现是不同的。因此libgles将是一个虚拟包sunxi-mali，ti-gfx并将成为提供者。

17.11.1。 virtual-package教程
在下面的示例中，我们将解释如何为其添加新的虚拟包（某些东西 - 虚拟）和提供者（某些提供者）。

首先，让我们创建虚拟包。

17.11.2。虚拟包的Config.in文件
该Config.in虚拟包的文件的东西，虚拟应包含以下内容：

01：config BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
02：布尔
03：
04：config BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL
05：取决于BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
06：字符串
在这个文件中，我们声明两个选项，BR2_PACKAGE_HAS_SOMETHING_VIRTUAL并且 BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL，其值将由供应商使用。

17.11.3节。虚拟包的.mk文件
该.mk虚拟包应该只是评估virtual-package宏：

01：################################################# ################################
02：＃
03：#thing-virtual
04：＃
05：################################################## ################################
06：
07：$（eval $（虚拟包））
使用host-virtual-package宏也可以使用目标和主机包 。

17.11.4。提供者的Config.in文件
将包作为提供者添加时，只Config.in需要对文件进行一些修改。

some-providerConfig.in包的文件，它提供了某些东西的功能-应该包含：

01：配置BR2_PACKAGE_SOME_PROVIDER
02：bool“some-provider”
03：选择BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
04：帮助
05：这是一个解释某些提供者是什么的评论。
06：
07：http：//foosoftware.org/some-provider/
08：
09：如果是BR2_PACKAGE_SOME_PROVIDER
10：config BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL
11：默认“some-provider”
12：endif
在第3行，我们选择BR2_PACKAGE_HAS_SOMETHING_VIRTUAL，在第11行，我们将值设置BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL为提供者的名称，但前提是它已被选中。

17.11.5。提供者的.mk文件
该.mk文件还应声明一个附加变量， SOME_PROVIDER_PROVIDES以包含它是以下实现的所有虚拟包的名称：

01：SOME_PROVIDER_PROVIDES =某事物 - 虚拟
当然，不要忘记为此包添加正确的构建和运行时依赖项！

17.11.6。有关依赖虚拟包的注意事项
添加需要FEATURE虚拟包提供的某个包时，必须使用depends on BR2_PACKAGE_HAS_FEATURE，如下所示：

config BR2_PACKAGE_HAS_FEATURE
布尔

config BR2_PACKAGE_FOO
bool“foo”
取决于BR2_PACKAGE_HAS_FEATURE
17.11.7。有关取决于特定提供商的说明
如果您的软件包确实需要特定的提供商，那么您必须将您的软件包作为depends on此提供商; 你不能 select提供者。

让我们以两个提供者为例FEATURE：

config BR2_PACKAGE_HAS_FEATURE
布尔

config BR2_PACKAGE_FOO
bool“foo”
选择BR2_PACKAGE_HAS_FEATURE

config BR2_PACKAGE_BAR
布尔“酒吧”
选择BR2_PACKAGE_HAS_FEATURE
并且您正在添加一个需要FEATURE提供的包foo，但不是由提供的包bar。

如果您要使用select BR2_PACKAGE_FOO，那么用户仍然可以BR2_PACKAGE_BAR在menuconfig中进行选择。这将导致配置不一致，从而FEATURE 一次启用两个相同的提供者，一个由用户显式设置，另一个由您隐式设置select。

相反，您必须使用depends on BR2_PACKAGE_FOO，这可以避免任何隐式配置不一致。

17,12。使用kconfig配置文件的软件包的基础结构
软件包处理用户指定配置的一种流行方式是kconfig。其中，它由Linux内核，Busybox和Buildroot本身使用。.config文件和menuconfig目标的存在是使用kconfig的两个众所周知的症状。

Buildroot为使用kconfig进行配置的软件包提供了基础结构。此基础结构提供必要的逻辑，menuconfig以foo-menuconfig在Buildroot中公开程序包的目标，并以正确的方式处理来回复制配置文件。

该kconfig-package架构是基于generic-package 基础设施。支持的所有变量generic-package也可用kconfig-package。更多详细信息，generic-package请参见 第17.5.2节“ 参考”。

为了使用kconfig-packageBuildroot包.mk的generic-package基础结构，除了基础结构所需的变量之外，文件中最低限度要求的行是：

FOO_KCONFIG_FILE = reference-to-source-configuration-file

$（eval $（kconfig-package））
此代码段会创建以下制作目标：

foo-menuconfig，它调用包的menuconfig目标
foo-update-config，将配置复制回源配置文件。设置片段文件时，无法使用此目标。
foo-update-defconfig，将配置复制回源配置文件。配置文件仅列出与默认值不同的选项。设置片段文件时，无法使用此目标。
并确保在适当的时候将源配置文件复制到构建目录。

指定要使用的配置文件有两个选项 FOO_KCONFIG_FILE（如上例所示）或FOO_KCONFIG_DEFCONFIG。必须提供，但不是两者：

FOO_KCONFIG_FILE 指定用于配置程序包的defconfig或full-config文件的路径。
FOO_KCONFIG_DEFCONFIG指定要调用以配置程序包的defconfig make规则。
除了这些最低限度要求的行之外，还可以设置几个可选变量以满足所考虑的包的需要：

FOO_KCONFIG_EDITORS：支持空格分隔的kconfig编辑器列表，例如menuconfig xconfig。默认情况下，menuconfig。
FOO_KCONFIG_FRAGMENT_FILES：以空格分隔的配置片段文件列表，这些文件合并到主配置文件中。片段文件通常在需要与上游（def）配置文件保持同步时使用，并进行一些小的修改。
FOO_KCONFIG_OPTS：调用kconfig编辑器时传递的额外选项。例如，这可能需要包括$（FOO_MAKE_OPTS）。默认情况下为空。
FOO_KCONFIG_FIXUP_CMDS：复制配置文件或运行kconfig编辑器后修复配置文件所需的shell命令列表。例如，可能需要这样的命令来确保与Buildroot的其他配置一致的配置。默认情况下为空。
FOO_KCONFIG_DOTCONFIG：文件的路径（带文件名）.config，相对于包源树。默认情况下，.config应该非常适合使用从Linux内核继承的标准kconfig基础结构的所有软件包; 一些包使用kconfig的衍生物，它使用不同的位置。
FOO_KCONFIG_DEPENDENCIES：解释此包的kconfig之前需要构建的包列表（很可能是主机包）。很少使用。默认情况下为空。
17.13。基于螺纹钢的包的基础设施
17.13.1。 rebar-package教程
首先，让我们看看如何.mk为基于rebar的包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#erlang-foobar
04：＃
05：################################################## ################################
06：
07：ERLANG_FOOBAR_VERSION = 1.0
08：ERLANG_FOOBAR_SOURCE = erlang-foobar - $（ERLAN{G}_{F}OOBA{R}_{V}ERSION）.tar.xz09：ERLAN{G}_{F}OOBA{R}_{S}ITE=http://www.foosoftware.org/download10：ERLAN{G}_{F}OOBA{R}_{D}EPENDENCIES=host-libaaalibbbb11：12：$（eval $（螺纹钢包装））
在第7行，我们声明了包的版本。

在第8行和第9行，我们声明了tarball的名称（建议使用xz-ed tarball）以及tar上的tarball位置。Buildroot将自动从此位置下载tarball。

在第10行，我们声明了我们的依赖项，以便在我们的包的构建过程开始之前构建它们。

最后，在第12行，我们调用rebar-package生成所有Makefile规则的宏，这些规则实际上允许构建包。

17.13.2。 rebar-package参考
rebar包基础结构的主要宏是 rebar-package。它类似于generic-package宏。使用host-rebar-package宏也可以使用主机包 。

就像通用基础设施一样，rebar基础设施通过在调用rebar-package 宏之前定义许多变量来工作。

首先，所有存在于通用基础架构包的元数据信息的变量也存在于rebar基础设施： ERLANG_FOOBAR_VERSION，ERLANG_FOOBAR_SOURCE， ERLANG_FOOBAR_PATCH，ERLANG_FOOBAR_SITE， ERLANG_FOOBAR_SUBDIR，ERLANG_FOOBAR_DEPENDENCIES， ERLANG_FOOBAR_INSTALL_STAGING，ERLANG_FOOBAR_INSTALL_TARGET， ERLANG_FOOBAR_LICENSE和ERLANG_FOOBAR_LICENSE_FILES。

rebar还可以定义一些特定于基础结构的附加变量。其中许多仅在非常特殊的情况下有用，因此典型的包只会使用其中的一些。

ERLANG_FOOBAR_USE_AUTOCONF，指定程序包在配置步骤中使用 autoconf。当包将此变量设置为时YES，将使用autotools基础结构。

注意。 您还可以使用一些变量从autotools 基础设施：ERLANG_FOOBAR_CONF_ENV，ERLANG_FOOBAR_CONF_OPTS， ERLANG_FOOBAR_AUTORECONF，ERLANG_FOOBAR_AUTORECONF_ENV和 ERLANG_FOOBAR_AUTORECONF_OPTS。

ERLANG_FOOBAR_USE_BUNDLED_REBAR，指定该包具有捆绑版本的钢筋 并且应该使用它。有效值为YES或NO（默认值）。

注意。 如果软件包捆绑了一个rebar实用程序，但可以使用Buildroot提供的通用实用程序，只需说NO（即，不要指定此变量）。仅在必须使用 此程序包中捆绑的rebar实用程序时才设置。

ERLANG_FOOBAR_REBAR_ENV，指定要传递给rebar实用程序的其他环境变量。
使用钢筋基础架构，已经定义了构建和安装软件包所需的所有步骤，并且它们通常适用于大多数基于钢筋的软件包。但是，在需要时，仍然可以自定义在任何特定步骤中执行的操作：

通过添加后操作挂钩（在解压缩，补丁，配置，构建或安装之后）。有关详细信息，请参见第17.21节“各种构建步骤中可用的挂钩”。
通过覆盖其中一个步骤。例如，即使使用了钢筋基础结构，如果包.mk文件定义了自己的ERLANG_FOOBAR_BUILD_CMDS变量，也将使用它来代替默认的钢筋变量。但是，使用此方法应限于非常具体的情况。在一般情况下不要使用它。
17.14。基于Waf的软件包的基础结构
17.14.1。 waf-package教程
首先，让我们看看如何.mk为基于Waf的包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#libfoo
04：＃
05：################################################## ################################
06：
07：LIBFOO_VERSION = 1.0
08：LIBFOO_SOURCE = libfoo - $（LIBFO{O}_{V}ERSION）.tar.gz09：LIBFO{O}_{S}ITE=http://www.foosoftware.org/download10：LIBFO{O}_{C}ON{F}_{O}PTS=--enable-bar--disable-baz11：LIBFO{O}_{D}EPENDENCIES=吧12：13：$（eval $（waf-package））
在第7行，我们声明了包的版本。

在第8行和第9行，我们声明了tarball的名称（建议使用xz-ed tarball）以及tar上的tarball位置。Buildroot将自动从此位置下载tarball。

在第10行，我们告诉Buildroot为libfoo启用哪些选项。

在第11行，我们告诉Buildroot libfoo的权限。

最后，在第13行，我们调用waf-package 生成所有Makefile规则的宏，这些规则实际上允许构建包。

17.14.2。 waf-package参考
Waf包基础结构的主要宏是waf-package。它类似于generic-package宏。

就像通用基础设施一样，Waf基础设施通过在调用waf-package 宏之前定义许多变量来工作。

首先，所有存在于通用基础架构包的元数据信息的变量也存在于WAF基础设施： LIBFOO_VERSION，LIBFOO_SOURCE，LIBFOO_PATCH，LIBFOO_SITE， LIBFOO_SUBDIR，LIBFOO_DEPENDENCIES，LIBFOO_INSTALL_STAGING， LIBFOO_INSTALL_TARGET。

还可以定义特定于Waf基础结构的附加变量。

LIBFOO_NEEDS_EXTERNAL_WAF可以设置为YES或NO告诉Buildroot使用捆绑的waf可执行文件。如果设置为NO默认值，那么Buildroot将使用包源树中提供的waf可执行文件; 如果设置为YES，那么Buidlroot将下载，安装waf作为主机工具并使用它来构建包。
LIBFOO_WAF_OPTS，指定waf在程序包构建过程的每个步骤传递给脚本的其他选项 ：configure，build和installation。默认情况下为空。
LIBFOO_CONF_OPTS，指定传递给waf配置步骤的脚本的其他选项 。默认情况下为空。
LIBFOO_BUILD_OPTS，指定waf在构建步骤中传递给脚本的其他选项 。默认情况下为空。
LIBFOO_INSTALL_STAGING_OPTS，指定waf在分段安装步骤中传递给脚本的其他选项。默认情况下为空。
LIBFOO_INSTALL_TARGET_OPTS，指定waf在目标安装步骤中传递给脚本的其他选项。默认情况下为空。
17.15。基于Meson的包的基础结构
17.15.1。 meson-package教程
Meson是一个开源构建系统，意味着速度非常快，更重要的是，尽可能方便用户使用。它使用Ninja作为配套工具来执行实际的构建操作。

让我们看看如何.mk为基于Meson的包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#foo
04：＃
05：################################################## ################################
06：
07：FOO_VERSION = 1.0
08：FOO_SOURCE = foo - $（FO{O}_{V}ERSION）.tar.gz09：FO{O}_{S}ITE=http://www.foosoftware.org/download10：FO{O}_{L}ICENSE=GPL-3.0+11：FO{O}_{L}ICENS{E}_{F}ILES=正在复制12：FO{O}_{I}NSTAL{L}_{S}TAGING=YES13：14：FO{O}_{D}EPENDENCIES=host-pkgconf栏15：16：ifeq（$（BR2_PACKAGE_BAZ），y）
17：FOO_CONF_OPTS + = -Dbaz = true
18：FOO_DEPENDENCIES + = baz
19：否则
20：FOO_CONF_OPTS + = -Dbaz = false
21：endif
22：
23：$（eval $（meson-package））
Makefile以包声明的标准变量的定义开始（第7行到第11行）。

在第23行，我们调用meson-package生成所有Makefile规则的宏，这些规则实际上允许构建包。

在这个例子中，host-pkgconf并bar声明为依赖关系 FOO_DEPENDENCIES在第14行，因为介子建立的文件foo的用途 pkg-config，以确定编译标志和包装的库bar。

请注意，没有必要添加 包host-meson的FOO_DEPENDENCIES变量，因为Meson包基础结构会根据需要自动添加此基本依赖项。

如果选择了“baz”的包，则对于在“富”所述“baz”的功能支持，通过添加活化-Dbaz=true到FOO_CONF_OPTS在线路17，作为中指定meson_options.txt在“foo”的源树文件。“baz”包也被添加到FOO_DEPENDENCIES。请注意baz，如果未选择包，则在第20行显式禁用支持。

总而言之，要添加一个新的基于介子的包，可以逐字复制Makefile示例，然后编辑它以用FOO新包的大写名称替换所有出现的内容并更新标准变量的值。

17.15.2。 meson-package参考
Meson包基础结构的主要宏是meson-package。它类似于generic-package宏。使用host-meson-package宏也可以使用目标和主机包。

就像通用基础设施一样，Meson基础设施通过在调用meson-package宏之前定义许多变量来工作。

首先，所有存在于通用基础架构包的元数据信息的变量也存在于介子基础设施：FOO_VERSION， FOO_SOURCE，FOO_PATCH，FOO_SITE，FOO_SUBDIR，FOO_DEPENDENCIES， FOO_INSTALL_STAGING，FOO_INSTALL_TARGET。

还可以定义一些特定于Meson基础结构的附加变量。其中许多仅在非常特殊的情况下有用，因此典型的包只会使用其中的一些。

FOO_CONF_ENV，指定要传递给meson配置步骤的其他环境变量 。默认情况下为空。
FOO_CONF_OPTS，指定要传递给meson配置步骤的其他选项。默认情况下为空。
FOO_NINJA_ENV，指定要传递给的附加环境变量 ninja，负责构建操作的介子配套工具。默认情况下为空。
17.16。集成基于货物的包裹
Cargo是Rust编程语言的包管理器。它允许用户构建用Rust编写的程序或库，但它也会下载和管理它们的依赖项，以确保可重复的构建。货物包裹被称为“板条箱”。

17.16.1。基于货物的包裹的Config.in文件
在Config.in基于货包的文件FOO应包含以下内容：

01：配置BR2_PACKAGE_FOO
02：bool“foo”
03：取决于BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS
04：选择BR2_PACKAGE_HOST_CARGO
05：帮忙
06：这是一个解释foo是什么的评论。
07：
08：http：//foosoftware.org/foo/
17.16.2。基于货物的包裹的.mk文件
Buildroot（尚未）为基于货物的包提供专用的包基础设施。因此，我们将解释如何.mk为这样的包编写文件。让我们从一个例子开始：

01：################################################# ################################
02：＃
03：#foo
04：＃
05：################################################## ################################
06：
07：FOO_VERSION = 1.0
08：FOO_SOURCE = foo - $（FOO_VERSION）.tar.gz
09：FOO_SITE = http://www.foosoftware.org/download
10：FOO_LICENSE = GPL-3.0 +
11：FOO_LICENSE_FILES =正在复制
12：
13：FOO_DEPENDENCIES =主机货物
14：
15：FOO_CARGO_ENV = CARGO_HOME = $（HOST_DIR）/分享/货物
16：FOO_CARGO_MODE = $（如果$（BR2_ENABLE_DEBUG），调试，发布）
17：
18：FOO_BIN_DIR = target / $（RUSTC_TARGET_NAME）/ $（FOO_CARGO_MODE）
19：
20：FOO_CARGO_OPTS =
21： - $（FOO_CARGO_MODE）
22： - target = $（RUSTC_TARGET_NAME）
23： - manifest-path = $（@D）/Cargo.toml24：25：定义FO{O}_{B}UIL{D}_{C}MDS26：$（TARGET_MAKE_ENV）KaTeX parse error: Expected 'EOF', got '\ ' at position 16: （FOO_CARGO_ENV）\̲ ̲27：货物建造（FOO_CARGO_OPTS）
28：恩赐
29：
30：定义FOO_INSTALL_TARGET_CMDS
31：$（INSTALL）-D -m 0755 $（@ D）/ KaTeX parse error: Expected 'EOF', got '\ ' at position 20: …_BIN_DIR）/ foo \̲ ̲32：（TARGET_DIR）/ usr / bin / foo
33：恩赐
34：
35：$（eval $（generic-package））
Makefile以包声明的标准变量的定义开始（第7行到第11行）。

如第35行所示，它基于 generic-package基础结构 第17.5.1节“ generic-package教程”。因此，它定义了此特定基础架构所需的变量，其中调用了Cargo：

FOO_BUILD_CMDS：调用Cargo来执行构建。配置包的交叉编译所需的选项通过 FOO_CONF_OPTS。
FOO_INSTALL_TARGET_CMDS：生成的二进制可执行文件安装在目标上。
为了使Cargo可用于构建，FOO_DEPENDENCIES需要包含host-cargo。

总而言之，要添加一个新的基于Cargo的包，可以逐字复制Makefile示例，然后进行编辑，以使用FOO新包的大写名称替换所有出现的内容，并更新标准变量的值。

17.16.3。关于依赖关系管理
包可以依赖于其Cargo.toml文件中列出的crates.io或git存储库中的其他库。在开始构建之前，Cargo通常会自动下载它们。此步骤也可以通过cargo fetch命令独立 执行。

Cargo维护注册表索引的本地缓存以及crate的git checkout，其位置由下式给出$CARGO_HOME。如第15行的Makefile示例中所示，此环境变量设置为 $(HOST_DIR)/share/cargo。

执行脱机构建时，此依赖性下载机制不方便，因为Cargo将无法获取依赖项。在这种情况下，建议使用并生成依赖关系的tarball cargo vendor并将其添加到 FOO_EXTRA_DOWNLOADS。

17.17。Go包的基础设施
此基础结构适用于使用标准构建系统并使用捆绑依赖项的Go包。

17.17.1。 golang-package教程
首先，让我们看看如何.mk为go包编写文件，并举例说明：

01：################################################# ################################
02：＃
03：#foo
04：＃
05：################################################## ################################
06：
07：FOO_VERSION = 1.0
08：FOO_SITE = $（调用github，bar，foo，$（FOO_VERSION））
09：FOO_LICENSE = BSD-3-Clause
10：FOO_LICENSE_FILES =许可证
11：
12：$（eval $（golang-package））
在第7行，我们声明了包的版本。

在第8行，我们声明了包的上游位置，这里是从Github获取的，因为在Github上托管了大量的Go包。

在第9行和第10行，我们提供有关包裹的许可详情。

最后，在第12行，我们调用golang-package生成所有Makefile规则的宏，这些规则实际上允许构建包。

17.17.2。 golang-package参考
在他们的Config.in文件中，使用golang-package 基础结构的包应该依赖于BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS 并且BR2_PACKAGE_HOST_GO_CGO_LINKING_SUPPORTS因为Buildroot会自动添加host-go对这些包的依赖。

Go包基础结构的主要宏是 golang-package。它类似于generic-package宏。仅支持目标包golang-package。

就像通用基础设施一样，Go基础设施通过在调用之前定义一些变量来工作golang-package。

所有存在于包的元数据信息的变量 通用包基础设施 第17.5.2，“ generic-package参考”同样存在于围棋基础设施：FOO_VERSION，FOO_SOURCE， FOO_PATCH，FOO_SITE，FOO_SUBDIR，FOO_DEPENDENCIES， FOO_LICENSE，FOO_LICENSE_FILES，FOO_INSTALL_STAGING，等。

请注意，没有必要添加包host-go的 FOO_DEPENDENCIES变量，因为Go包基础结构会根据需要自动添加此基本依赖关系。

根据包的需要，可以选择定义一些特定于Go基础结构的附加变量。其中许多仅在非常特殊的情况下有用，因此典型的包只会使用其中的一些，或者不使用。

如果您的包需要GOPATH编译自定义，则可以使用该FOO_WORKSPACE变量。在GOPATH使用会 /。如果FOO_WORKSPACE未指定，则默认为_gopath。
FOO_SRC_SUBDIR是您的源将相对于您的源编译的子目录GOPATH。一个示例值是 github.com/bar/foo。如果FOO_SRC_SUBDIR未指定，则默认为FOO_SITE变量的值。
FOO_LDFLAGS并且FOO_TAGS可以用于分别传递LDFLAGS或者传递 TAGS给go构建命令。
FOO_BUILD_TARGETS可用于传递应构建的目标列表。如果FOO_BUILD_TARGETS未指定，则默认为.。然后我们有两个案例：

FOO_BUILD_TARGETS是.。在这种情况下，我们假设只生成一个二进制文件，默认情况下我们将它命名为包名称。如果这不合适，可以使用覆盖生成的二进制文件的名称FOO_BIN_NAME。
FOO_BUILD_TARGETS不是.。在这种情况下，我们迭代值来构建每个目标，并为每个目标生成一个二进制文件，它是目标的非目录组件。例如，如果生成 FOO_BUILD_TARGETS = cmd/docker cmd/dockerd的二进制文件是docker和dockerd。
FOO_INSTALL_BINS可用于传递应安装在/usr/bin目标上的二进制文件列表。如果 FOO_INSTALL_BINS未指定，则默认为包的小写名称。
使用Go基础结构，已经定义了构建和安装软件包所需的所有步骤，并且它们通常适用于大多数基于Go的软件包。但是，在需要时，仍然可以自定义在任何特定步骤中执行的操作：

通过添加后操作挂钩（在解压缩，补丁，配置，构建或安装之后）。有关详细信息，请参见第17.21节“各种构建步骤中可用的挂钩”。
通过覆盖其中一个步骤。例如，即使使用Go基础结构，如果包.mk文件定义了自己的 FOO_BUILD_CMDS变量，也将使用它而不是默认的Go。但是，使用此方法应限于非常具体的情况。在一般情况下不要使用它。
17.18。构建内核模块的包的基础结构
Buildroot提供了一个帮助程序基础结构，可以轻松编写构建和安装Linux内核模块的软件包。有些软件包只包含内核模块，其他软件包除内核模块外还包含程序和库。Buildroot的帮助基础设施支持这两种情况。

17.18.1。 kernel-module教程
让我们从一个示例开始，介绍如何准备一个只构建内核模块的简单包，而不是其他组件：

01：################################################# ################################
02：＃
03：#foo
04：＃
05：################################################## ################################
06：
07：FOO_VERSION = 1.2.3
08：FOO_SOURCE = foo - $（FO{O}_{V}ERSION）.tar.xz09：FO{O}_{S}ITE=http://www.foosoftware.org/download10：FO{O}_{L}ICENSE=GPL-2.011：FO{O}_{L}ICENS{E}_{F}ILES=正在复制12：13：$（eval $（kernel-module））14：$（eval $（generic-package））
第7-11行定义了通常的元数据，以指定版本，存档名称，远程URI在何处查找包源，许可信息。

在第13行，我们调用kernel-module帮助程序基础结构，该基础结构生成所有适当的Makefile规则和变量以构建该内核模块。

最后，在第14行，我们调用 generic-package基础结构 第17.5.1节“ generic-package教程”。

依赖于linux自动添加，因此不需要在其中指定它FOO_DEPENDENCIES。

您可能已经注意到，与其他包基础结构不同，我们明确地调用了第二个基础结构。这允许包构建内核模块，但如果需要，还可以使用任何其他包基础结构来构建普通的用户空间组件（库，可执行文件…）。单靠使用kernel-module基础设施是不够的; 另一个包基础设施必须使用。

让我们看一个更复杂的例子：

01：################################################# ################################
02：＃
03：#foo
04：＃
05：################################################## ################################
06：
07：FOO_VERSION = 1.2.3
08：FOO_SOURCE = foo - $（FOO_VERSION）.tar.xz
09：FOO_SITE = http://www.foosoftware.org/download
10：FOO_LICENSE = GPL-2.0
11：FOO_LICENSE_FILES =正在复制
12：
13：FOO_MODULE_SUBDIRS = driver / base
14：FOO_MODULE_MAKE_OPTS = KVERSION = $（LINU{X}_{V}ERSIO{N}_{P}ROBED）15：16：ifeq（$（BR2_PACKAGE_LIBBAR），y）
17：FOO_DEPENDENCIES = libbar
18：FOO_CONF_OPTS = --enable-bar
19：FOO_MODULE_SUBDIRS + =司机/酒吧
20：否则
21：FOO_CONF_OPTS = - 禁用条
22：endif
23：
24：$（eval $（内核模块））26：$（eval $（autotools-package））
在这里，我们看到我们有一个基于autotools的包，它还构建了位于子目录中的内核模块driver/base，如果启用了libbar，则内核模块位于子目录中driver/bar，并定义KVERSION要传递给Linux 的变量构建模块时构建系统。

17.18.2。 kernel-module参考
内核模块基础结构的主要宏是kernel-module。与其他包基础结构不同，它不是独立的，并且需要*-package在其后调用任何其他宏。

该kernel-module宏定义了构建内核模块的后构建和后目标安装钩子。如果包.mk需要访问构建的内核模块，它应该在post-build钩子中进行， 在调用之后注册kernel-module。类似地，如果软件包.mk在安装后需要访问内核模块，它应该在安装后挂钩中进行，在 调用后注册kernel-module。这是一个例子：

$（eval $（kernel-module））

定义FOO_DO_STUFF_WITH_KERNEL_MODULE
＃做点什么…
endef
FOO_POST_BUILD_HOOKS + = FOO_DO_STUFF_WITH_KERNEL_MODULE

$（eval $（generic-package））
最后，与其他包基础结构host-kernel-module不同，构建主机内核模块没有 变体。

可以选择定义以下附加变量以进一步配置内核模块的构建：

FOO_MODULE_SUBDIRS可以设置为内核模块源所在的一个或多个子目录（相对于包源顶级目录）。如果为空或未设置，则认为内核模块的源位于包源树的顶部。
FOO_MODULE_MAKE_OPTS 可以设置为包含额外的变量定义以传递给Linux构建系统。
您也可以参考（但您可能不会设置！）这些变量：

LINUX_DIR 包含提取和构建Linux内核的路径。
LINUX_VERSION 包含用户配置的版本字符串。
LINUX_VERSION_PROBED 包含内核的真实版本字符串，通过运行检索 make -C $(LINUX_DIR) kernelrelease
KERNEL_ARCH包含当前架构的名称，例如arm， mips…
17.19。asciidoc文档的基础结构
您当前正在阅读的Buildroot手册完全使用AsciiDoc标记语法编写。然后手册呈现为多种格式：

HTML
分HTML
PDF格式
EPUB
文本
尽管Buildroot只包含一个用AsciiDoc编写的文档，但对于包，还有一个使用AsciiDoc语法呈现文档的基础结构。

对于包，AsciiDoc基础结构可以从br2外部树 第9.2节“在 Buildroot 之外保留自定义”中获得。这允许br2外部树的文档与Buildroot文档匹配，因为它将呈现为相同的格式并使用相同的布局和主题。

17.19.1。 asciidoc-document教程
封装基础结构后缀-package，文档基础结构后缀-document。因此，AsciiDoc基础架构已命名asciidoc-document。

这是一个呈现简单的AsciiDoc文档的示例。

01：################################################# ################################
02：＃
03：#foo-document
04：＃
05：################################################## ################################
06：
07：FOO_SOURCES = $（排序$（通配符$（pkgdir）/\ast ））08：$（eval $（调用asciidoc-document））
在第7行，Makefile声明了文档的来源。目前，预计该文件的来源仅为本地; Buildroot不会尝试下载任何内容来呈现文档。因此，您必须指明来源的位置。通常，上面的字符串足以用于没有子目录结构的文档。

在第8行，我们调用该asciidoc-document函数，该函数生成呈现文档所需的所有Makefile代码。

17.19.2。 asciidoc-document参考
可以在.mk文件中设置以提供元数据信息的变量列表是（假设文档名称为foo）：

FOO_SOURCES，必需，定义文档的源文件。
FOO_RESOURCES，optional，可以包含一个以空格分隔的路径列表，这些路径指向包含所谓资源（如CSS或图像）的一个或多个目录。默认情况下为空。
FOO_DEPENDENCIES，可选，在构建此文档之前必须构建的包列表（很可能是主机包）。如果文档的钩子需要访问Kconfig结构，则可以添加prepare-kconfig到依赖项列表中。
还有其他钩子（有关钩子的一般信息，请参见第17.21节“各种构建步骤中可用的钩子”），文档可以设置为定义在各个步骤中要执行的额外操作：

FOO_POST_RSYNC_HOOKS在Buildroot复制源之后运行其他命令。例如，这可以用于生成具有从树中提取的信息的手册的一部分。例如，Buildroot使用此挂钩生成附录中的表。
FOO_CHECK_DEPENDENCIES_HOOKS对所需组件运行其他测试以生成文档。在AsciiDoc中，可以调用过滤器，即将解析AsciiDoc块并适当渲染它的程序（例如ditaa或 aafigure）。
FOO_CHECK_DEPENDENCIES__HOOKS，为指定的格式运行其他测试（请参阅上面的呈现格式列表）。
这是一个使用所有变量和所有钩子的完整示例：

01：################################################# ################################
02：＃
03：#foo-document
04：＃
05：################################################## ################################
06：
07：FOO_SOURCES = $（排序$（通配符$（pkgdir）/ *））
08：FOO_RESOURCES = $（排序$（通配符$（pkgdir）/ ressources））
09：
10：定义FOO_GEN_EXTRA_DOC
11：/ path / to / generate-script --outdir = KaTeX parse error: Expected 'EOF', got '\ ' at position 123: … null 2>＆1; 然后 \̲ ̲17：echo“你需要my-p…（eval $（调用asciidoc-document））
17.20。特定于Linux内核包的基础结构
Linux内核包可以使用一些基于包钩子的特定基础结构来构建Linux内核工具或/和构建Linux内核扩展。

17.20.1。Linux内核工具
Buildroot提供了一个帮助程序基础结构，可以为Linux内核源中可用的目标构建一些用户空间工具。由于它们的源代码是内核源代码的一部分，因此linux-tools存在一个特殊的包，并重新使用在目标上运行的Linux内核的源代码 。

我们来看一个Linux工具的例子。对于名为的新Linux工具 foo，在现有的新菜单条目中创建 package/linux-tools/Config.in。此文件将包含与将在配置工具中使用和显示的每个内核工具相关的选项说明。它基本上看起来像：

01：config BR2_PACKAGE_LINUX_TOOLS_FOO
02：bool“foo”
03：选择BR2_PACKAGE_LINUX_TOOLS
04：帮助
05：这是一个解释foo内核工具的注释。
06：
07：http：//foosoftware.org/foo/
选项的名称以前缀开头BR2_PACKAGE_LINUX_TOOLS_，后跟工具的大写名称（就像对包一样）。

注意。 与其他软件包不同，linux-tools软件包选项显示在 子菜单linux下的内核Linux Kernel Tools菜单中，而不是在子菜单下Target packages主菜单下。

然后为每个linux工具添加一个.mk.in名为的新文件 package/linux-tools/linux-tool-foo.mk.in。它基本上看起来像：

01：################################################# ################################
02：＃
03：#foo
04：＃
05：################################################## ################################
06：
07：LINUX_TOOLS + = foo
08：
09：FOO_DEPENDENCIES = libbbb
10：
11：定义FOO_BUILD_CMDS
12：$（TARGE{T}_{M}AK{E}_{E}NV）$（MAKE）-C $（LINU{X}_{D}IR）/toolsfoo13：恩赐14：15：定义FO{O}_{I}NSTAL{L}_{S}TAGIN{G}_{C}MDS16：$（TARGET_MAKE_ENV）$（MAKE）-C $（LINUX_DIR）/工具
17：DESTDIR = KaTeX parse error: Expected 'EOF', got '\ ' at position 14: （STAGING_DIR）\̲ ̲18：foo_install …（TARGET_MAKE_ENV）$（MAKE）-C $（LINUX_DIR）/工具
23：DESTDIR = $（TARGET_DIR）
24：foo_install
25：恩赐
在第7行，我们将Linux工具注册foo到可用的Linux工具列表中。

在第9行，我们指定了该工具所依赖的依赖项列表。仅当foo选择工具时，才会将这些依赖项添加到Linux软件包依赖项列表中 。

Makefile的其余部分，第11-25行定义了应该在Linux工具构建过程的不同步骤中完成的操作，如 第17.5.1节“ 教程”。它们实际上仅在选择工具时使用。唯一支持的命令是 ，和。generic package generic-packagefoo_BUILD_CMDS_INSTALL_STAGING_CMDS_INSTALL_TARGET_CMDS

注意。 一个人不得打电话$(eval $(generic-package))或任何其他包裹基础设施！Linux工具本身不是包，它们是linux-tools包的一部分。

17.20.2。Linux内核的扩展
某些软件包提供了需要修改Linux内核树的新功能。这可以是要在内核树上应用的补丁的形式，也可以是要添加到树中的新文件的形式。Buildroot的Linux内核扩展基础结构提供了一个简单的解决方案，可以在提取内核源代码之后和应用内核补丁之前自动执行此操作。使用此机制打包的扩展示例包括Xenomai和RTAI的实时扩展，以及一组树外LCD屏幕驱动程序fbtft。

让我们看一个关于如何添加新Linux扩展的示例foo。

首先，创建foo提供扩展的包：此包是标准包; 请参阅前面有关如何创建此类包的章节。该软件包负责下载源存档，检查哈希，定义许可信息以及构建用户空间工具（如果有）。

然后正确创建Linux扩展：在现有的菜单项中创建一个新的菜单项linux/Config.ext.in。此文件包含与将在配置工具中使用和显示的每个内核扩展相关的选项说明。它基本上看起来像：

01：配置BR2_LINUX_KERNEL_EXT_FOO
02：bool“foo”
03：帮助
04：这是一个解释foo内核扩展的注释。
05：
06：http：//foosoftware.org/foo/
然后为每个linux扩展添加一个.mk名为的新文件 linux/linux-ext-foo.mk。它应该基本上包含：

01：################################################# ################################
02：＃
03：#foo
04：＃
05：################################################## ################################
06：
07：LINUX_EXTENSIONS + = foo
08：
09：定义FOO_PREPARE_KERNEL
10：$（FOO_DIR）/prepare-kernel-tree.sh --linux-dir = $（@ D）
11：恩赐
在第7行，我们将Linux扩展添加foo到可用的Linux扩展列表中。

在第9-11行，我们定义扩展应该做什么来修改Linux内核树; 这是特定于linux扩展并且可以使用foo包定义的变量，如：$(FOO_DIR)或 $(FOO_VERSION)…以及所有Linux变量，如： $(LINU{X}_{V}ERSION)或$(LINUX_VERSION_PROBED)，$(KERNEL_ARCH)…请参见那些内核变量 的定义第17.18.2节“ kernel-module引用”。

17.21。钩子可用于各种构建步骤
通用基础结构（以及派生的autotools和cmake基础结构）也允许包指定挂钩。这些定义了在现有步骤之后执行的其他操作。大多数钩子对于通用包都不是很有用，因为该.mk 文件已经完全控制了在包构造的每个步骤中执行的操作。

以下挂钩点可用：

LIBFOO_PRE_DOWNLOAD_HOOKS
LIBFOO_POST_DOWNLOAD_HOOKS
LIBFOO_PRE_EXTRACT_HOOKS
LIBFOO_POST_EXTRACT_HOOKS
LIBFOO_PRE_RSYNC_HOOKS
LIBFOO_POST_RSYNC_HOOKS
LIBFOO_PRE_PATCH_HOOKS
LIBFOO_POST_PATCH_HOOKS
LIBFOO_PRE_CONFIGURE_HOOKS
LIBFOO_POST_CONFIGURE_HOOKS
LIBFOO_PRE_BUILD_HOOKS
LIBFOO_POST_BUILD_HOOKS
LIBFOO_PRE_INSTALL_HOOKS （仅适用于主机包）
LIBFOO_POST_INSTALL_HOOKS （仅适用于主机包）
LIBFOO_PRE_INSTALL_STAGING_HOOKS （仅限目标套餐）
LIBFOO_POST_INSTALL_STAGING_HOOKS （仅限目标套餐）
LIBFOO_PRE_INSTALL_TARGET_HOOKS （仅限目标套餐）
LIBFOO_POST_INSTALL_TARGET_HOOKS （仅限目标套餐）
LIBFOO_PRE_INSTALL_IMAGES_HOOKS
LIBFOO_POST_INSTALL_IMAGES_HOOKS
LIBFOO_PRE_LEGAL_INFO_HOOKS
LIBFOO_POST_LEGAL_INFO_HOOKS
这些变量是包含要在此挂钩点执行的操作的变量名称列表。这允许在给定的钩点处注册几个钩子。这是一个例子：

定义LIBFOO_POST_PATCH_FIXUP
措施1
动作2
endef

LIBFOO_POST_PATCH_HOOKS + = LIBFOO_POST_PATCH_FIXUP
17.21.1。使用POST_RSYNC钩子
该POST_RSYNC钩子仅适用于使用本地源，无论是通过包中运行local现场方法或OVERRIDE_SRCDIR 机制。在这种情况下，将使用rsync本地位置将包源复制到buildroot构建目录中。但是，该rsync 命令不会复制源目录中的所有文件。属于一个版本控制系统文件，如目录 .git，.hg等不会被复制。对于大多数软件包来说，这已足够，但是给定的软件包可以使用POST_RSYNC钩子执行其他操作。

原则上，钩子可以包含您想要的任何命令。但是，一个特定用例是使用有意复制版本控制目录rsync。rsync您在钩子中使用的命令可以使用以下变量：

$(SRCDIR)：被覆盖的源目录的路径
$(@D)：构建目录的路径
17.21.2。Target-finalize钩子
包也可以注册钩子LIBFOO_TARGET_FINALIZE_HOOKS。这些挂钩在构建所有包之后运行，但在生成文件系统映像之前运行。它们很少使用，你的软件包可能不需要它们。

17.22。Gettext集成和与包的交互
许多支持国际化的包使用gettext库。该库的依赖性相当复杂，因此值得一些解释。

在glibc的 C库集成了全面的落实 gettext的，支持翻译。因此，本地语言支持内置于glibc中。

另一方面，uClibc和musl C库仅提供gettext功能的存根实现，允许使用gettext函数编译库和程序，但不提供完整的gettext实现的转换功能。有了这样的C库，如果需要真正的本地语言支持，它可以由包的libintl库 提供gettext。

因此，为了确保正确处理本地语言支持，Buildroot中可以使用NLS支持的软件包应该：

确保在启用时启用NLS支持BR2_SYSTEM_ENABLE_NLS=y。这是针对autotools软件包自动完成的，因此只应对使用其他软件包基础结构的软件包进行此操作。
添加$(TARGE{T}_{N}L{S}_{D}EPENDENCIES)到包<pkg{>}_{D}EPENDENCIES变量。此添加应无条件地完成：核心基础结构自动调整此变量的值以包含相关的包列表。如果禁用NLS支持，则此变量为空。如果启用了NLS支持，则此变量包含，host-gettext以便在主机上可以使用编译转换文件所需的工具。此外，如果使用uClibc或musl，则此变量也包含gettext以获得完整的gettext实现。如果需要，添加$(TARGET_NLS_LIBS)到链接器标志，以便与包链接libintl。autotools软件包通常不需要这样做，因为它们通常会自动检测到它们应该链接libintl。但是，使用其他构建系统的程序包或有问题的基于autotools的程序包可能需要这样。$(TARGET_NLS_LIBS)应无条件地添加到链接器标志，因为核心会自动将其设置为空或-lintl根据配置定义。
不应对Config.in文件进行任何更改以支持NLS。

最后，某些包需要在目标上使用一些gettext实用程序，例如gettext程序本身，它允许从命令行检索已翻译的字符串。在这种情况下，包裹应该：

select BR2_PACKAGE_GETTEXT在他们的Config.in文件中 使用，在上面的注释中指出它只是一个运行时依赖。
不要gettext在DEPENDENCIES其.mk文件的变量中添加任何依赖项。
17.23。技巧和窍门
17.23.1。包名，配置项名和makefile变量关系
在Buildroot中，有一些关系：

的包名称，它是包目录名称（以及名称*.mk文件）;
在Config.in文件中声明的配置项名称;
makefile变量前缀。
必须使用以下规则维护这些元素之间的一致性：

包目录和*.mk名称是包名 本身（例如：）package/foo-bar_boo/foo-bar_boo.mk;
的化妆目标名称是包名本身（例如： foo-bar_boo）;
配置条目是大写的包名称，.其中- 字符替换为_，前缀为BR2_PACKAGE_（例如 ：）BR2_PACKAGE_FOO_BAR_BOO;
该*.mk文件变量前缀是上壳体包名称 与.和-与取代的字符_（例如： FOO_BAR_BOO_VERSION）。
17.23.2。如何检查编码风格
Buildroot提供了一个脚本，utils/check-package用于检查新的或更改的文件以获得编码样式。它不是一个完整的语言验证器，但它会遇到许多常见的错误。在创建提交补丁之前，它应在您创建或修改的实际文件中运行。

此脚本可用于包，文件系统makefile，Config.in文件等。它不会检查定义包基础结构的文件和包含类似公共代码的其他一些文件。

要使用它，请运行check-package脚本，告知您创建或更改了哪些文件：

$ ./utils/check-package包/ new-package / *
如果utils路径中有目录，则还可以运行：

$ cd package / new-package /
$ check-package *
该工具还可用于br2-external中的包：

$ check-package -b / path / to / br2-ext-tree / package / my-package / *
17.23.3。如何测试你的包裹
添加新软件包后，在各种条件下对其进行测试非常重要：它是否适用于所有体系结构？它是用不同的C库构建的吗？是否需要线程，NPTL？等等…

Buildroot运行autobuilders，持续测试随机配置。但是，这些只构建了mastergit树的 分支，而你的新花式包还没有。

Buildroot提供了一个脚本，utils/test-pkg它使用与autobuilders使用的相同的基本配置，因此您可以在相同的条件下测试您的包。

首先，创建一个配置代码段，其中包含启用程序包所需的所有必要选项，但不包含任何体系结构或工具链选项。例如，让我们创建一个只启用的配置代码段 libcurl，而不需要任何TLS后端：

$ cat libcurl.config
BR2_PACKAGE_LIBCURL = Y
如果您的软件包需要更多配置选项，则可以将它们添加到配置代码段。例如，这里是你如何测试libcurl与 openssl作为TLS后端和curl程序：

$ cat libcurl.config
BR2_PACKAGE_LIBCURL = Y
BR2_PACKAGE_CURL = Y
BR2_PACKAGE_OPENSSL = Y
然后运行test-pkg脚本，告诉它要使用哪个配置代码段以及要测试的包：

$ ./utils/test-pkg -c libcurl.config -p libcurl
默认情况下，test-pkg将针对autobuilders使用的工具链的子集构建您的软件包，Buildroot开发人员已将其选为最有用和最具代表性的子集。如果要测试所有工具链，请传递该-a选项。请注意，在任何情况下，都会排除内部工具链，因为它们需要很长时间才能构建。

输出列出了所有测试的工具链和相应的结果（摘录，结果是假的）：

$ ./utils/test-pkg -c libcurl.config -p libcurl
armv5-ctng-linux-gnueabi [1/11]：好的
armv7-ctng-linux-gnueabihf [2/11]：好的
br-aarch64-glibc [3/11]：SKIPPED
br-arcle-hs38 [4/11]：跳过
br-arm-basic [5/11]：失败
br-arm-cortex-a9-glibc [6/11]：好的
br-arm-cortex-a9-musl [7/11]：失败
br-arm-cortex-m4-full [8/11]：好的
br-arm-full [9/11]：好的
br-arm-full-nothread [10/11]：失败
br-arm-full-static [11/11]：好的
11个构建，2个跳过，2个构建失败，1个法律信息失败
结果意味着：

OK：构建成功。
SKIPPED：配置代码段中列出的一个或多个配置选项在最终配置中不存在。这是由于工具链不满足依赖性的选项，例如depends on BR2_USE_MMU具有noMMU工具链的包。丢失的选项missing.config在输出构建目录中报告（~/br-test-pkg/TOOLCHAIN_NAME/默认情况下）。
FAILED：构建失败。检查logfile输出构建目录中的文件以查看出错的地方：

实际构建失败，
法律信息失败了，
其中一个初步步骤（下载配置文件，应用配置，运行dirclean包）失败。
当出现故障时，您可以使用相同的选项重新运行脚本（修复程序包后）; 该脚本将尝试重新构建-p为所有工具链指定的包，而无需重新构建该包的所有依赖项。

该test-pkg脚本接受一些选项，您可以通过运行获得一些帮助：

$ ./utils/test-pkg -h
17.23.4。如何从GitHub添加包
GitHub上的软件包通常没有带有发布tarball的下载区域。但是，可以直接从GitHub上的存储库下载tarball。由于已知GitHub在过去已经改变了下载机制，因此应该使用github辅助函数，如下所示。

＃使用标记或完整提交ID
FOO_VERSION = v1.0
FOO_SITE = $（调用github，<user>，<package>，$（FOO_VERSION））
笔记

FOO_VERSION可以是标记或提交ID。
github生成的tarball名称与Buildroot中的默认名称匹配（例如:) foo-f6fb6654af62045239caed5950bc6c7971965e60.tar.gz，因此不必在.mk文件中指定它。
使用提交ID作为版本时，应使用完整的40个十六进制字符。
如果您要添加的软件包在GitHub上有一个发布部分，维护者可能已经上传了一个发布tarball，或者该发布可能只是指向git标签中自动生成的tarball。如果维护者上传了一个发布tarball，我们更喜欢使用它，因为它可能略有不同（例如它包含一个configure脚本，所以我们不需要做AUTORECONF）。

您可以在发布页面上看到它是上传的tarball还是git标记：

github_hash_mongrel2.png
如果它看起来像上面的图像那么它是由维护者上传的，你应该使用该链接（在该示例中： mongrel2-v1.9.2.tar.bz2）来指定FOO_SITE，而不是使用 github帮助器。
另一方面，如果只有 “源代码”链接，那么它是一个自动生成的tarball，你应该使用 github辅助函数。
17.24。结论
如您所见，向Buildroot添加软件包只是使用现有示例编写Makefile并根据程序包所需的编译过程对其进行修改。

如果您打包可能对其他人有用的软件，请不要忘记将修补程序发送到Buildroot邮件列表（请参见 第21.5节“提交补丁”）！

第18章修补包
在集成新软件包或更新现有软件包时，可能需要修补软件源以使其在Buildroot中交叉构建。

Buildroot提供了一个基础结构，可在构建期间自动处理此问题。它支持三种应用补丁集的方法：下载补丁，buildroot中提供的补丁和位于用户定义的全局补丁目录中的补丁。

18.1。提供补丁
18.1.1。下载
如果需要应用可供下载的修补程序，请将其添加到_PATCH变量中。如果条目包含://，则Buildroot将假定它是完整URL并从该位置下载补丁。否则，Buildroot将假定应该从中下载补丁_SITE。它可以是单个补丁，也可以是包含补丁系列的tarball。

与所有下载一样，应该将哈希添加到.hash 文件中。

此方法通常用于Debian的包。

18.1.2。在Buildroot内
大多数补丁都是在程序包目录中的Buildroot中提供的; 这些通常旨在修复交叉编译，libc支持或其他此类问题。

应该命名这些补丁文件-.patch。

笔记

Buildroot附带的补丁文件不应在其文件名中包含任何包版本引用。
补丁文件名中 的字段是指应用顺序，应从1开始; 最好用最多4位的零填充数字，就像git-format-patch一样。例如：0001-foobar-the-buz.patch
以前，补丁必须以包的名称为前缀，例如--.patch，但不再是这种情况。现有的包将随着时间的推移而修复。不要使用包名称为补丁添加前缀。
此前，一个series文件，如使用quilt，也可以在包目录添加的。在这种情况下，该series文件定义补丁应用程序顺序。这已弃用，将来会被删除。 不要使用系列文件。
18.1.3。全局补丁目录
该BR2_GLOBAL_PATCH_DIR配置文件的选项可以被用于指定包含全球包贴片的一个或多个目录的空间分隔的列表。有关详细信息，请参见第9.8节“添加项目特定的修补程序”。

18.2。如何应用补丁
_PRE_PATCH_HOOKS如果已定义，则 运行命令;
清理构建目录，删除所有现有*.rej文件;
如果_PATCH已定义，则应用来自这些tarball的补丁;
如果*.patch包的Buildroot目录或命名的包子目录中有一些文件，则：

如果series包目录中存在文件，则根据该series文件应用补丁;
否则，匹配的补丁文件*.patch按字母顺序应用。因此，为了确保以正确的顺序应用它们，强烈建议将补丁文件命名为： -.patch，其中指的是 应用顺序。
如果BR2_GLOBAL_PATCH_DIR已定义，则将按指定的顺序枚举目录。如前一步骤中所述应用补丁。
_POST_PATCH_HOOKS如果已定义，请 运行命令。
如果在步骤3或4中出现问题，则构建失败。

18.3。包修补程序的格式和许可
修补程序在与其适用的软件相同的许可下发布（请参见第12.2节“遵守Buildroot许可证”）。

应该在补丁的标题注释中添加一条消息，说明补丁的作用以及补丁的原因。

您应该Signed-off-by在每个修补程序的标头中添加一个语句，以帮助跟踪更改并证明该修补程序是在与修改的软件相同的许可证下发布的。

如果软件受版本控制，建议使用上游SCM软件生成补丁集。

否则，将标头与diff -purN package-version.orig/ package-version/命令的输出连接起来 。

如果更新现有修补程序（例如，在碰撞程序包版本时），请确保不删除现有的From标头和Signed-off-by标记，但在适当时更新补丁注释的其余部分。

最后，补丁应该如下所示：

configure.ac：添加C ++支持测试

签名：John Doe [email protected]

— configure.ac.orig
+++ configure.ac
@@ -40,2 +40,12 @@

AC_PROG_MAKE_SET
+

• AC_CACHE_CHECK（[C ++编译器是否有效]，
• [rw_cv_prog_cxx_works]，
• [AC_LANG_PUSH（[C ++]）
• AC_LINK_IFELSE（[AC_LANG_PROGRAM（[]，[]）]，
• [rw_cv_prog_cxx_works = yes]，
• [rw_cv_prog_cxx_works = no]）
• AC_LANG_POP（[C ++]）]）
• AM_CONDITIONAL（[CXX_WORKS]，[test“x $ rw_cv_prog_cxx_works”=“xyes”]）
  18.4。集成Web上的补丁
  在集成您不是作者的补丁时，您必须在补丁本身的标题中添加一些内容。

根据补丁是从项目存储库本身获取还是从Web上的某个位置获取，请添加以下标记之一：

反向移植自：
要么

取自：
在补丁中添加一些可能必要的更改也是明智的。

第19章下载基础结构
去做

第20章调试Buildroot
可以Buildroot在构建包时检测步骤。定义变量BR2_INSTRUMENTATION_SCRIPTS以包含一个空格分隔列表中的一个或多个脚本（或其他可执行文件）的路径，您希望在每个步骤之前和之后调用它。脚本按顺序调用，有三个参数：

start或end表示步骤的开始（或结束）;
即将开始的步骤的名称，或刚刚结束的步骤的名称;
包的名称。
例如 ：

make BR2_INSTRUMENTATION_SCRIPTS =“/ path / to / my / script1 / path / to / my / script2”
步骤列表是：

extract
patch
configure
build
install-host，当安装主机包时 $(HOST_DIR)
install-target，当安装目标包时 $(TARGET_DIR)
install-staging，当安装目标包时 $(STAGING_DIR)
install-image，当target-package安装文件时 $(BINARIES_DIR)
该脚本可以访问以下变量：

BR2_CONFIG：Buildroot .config文件的路径
HOST_DIR，STAGING_DIR，TARGET_DIR：见 第17.5.2，“ generic-package参考”
BUILD_DIR：提取和构建包的目录
BINARIES_DIR：存储所有二进制文件（即图像）的位置
BASE_DIR：基本输出目录
第21章。对Buildroot的贡献
您可以通过多种方式为Buildroot做出贡献：分析和修复错误，分析和修复autobuilders检测到的包构建失败，测试和审查其他开发人员发送的补丁，处理我们的TODO列表中的项目以及发送您自己的改进到Buildroot或其手册。以下部分提供了有关这些项目的更多详细信息。

如果您有兴趣为Buildroot做贡献，那么您应该做的第一件事就是订阅Buildroot邮件列表。此列表是与其他Buildroot开发人员交互并向其发送贡献的主要方式。如果您尚未订阅，请参阅 第5章，订阅链接的社区资源。

如果您要触摸代码，强烈建议使用Buildroot的git存储库，而不是从提取的源代码tarball开始。Git是从补丁开发并直接将补丁发送到邮件列表的最简单方法。 有关获取Buildroot git树的更多信息，请参阅第3章，获取Buildroot。

21.1。重现，分析和修复错误
第一种贡献方式是查看Buildroot bug跟踪器中的开放错误报告。当我们努力使错误数量尽可能小时，所有帮助复制，分析和修复报告的错误都非常受欢迎。即使您还没有看到完整的图片，也要毫不犹豫地向报告您的发现的错误报告添加评论。

21.2。分析和修复autobuild故障
Buildroot autobuilders是一组构建机器，可以根据随机配置连续运行Buildroot构建。这适用于Buildroot支持的所有体系结构，具有各种工具链，以及随机选择的包。通过Buildroot上的大型提交活动，这些autobuilder可以在提交后很早就检测到问题。

所有构建结果均可在http://autobuild.buildroot.org上获得，统计数据位于http://autobuild.buildroot.org/stats.php。每天，所有失败包的概述都会发送到邮件列表。

检测问题很好，但显然这些问题也必须修复。非常欢迎您的贡献！基本上有两件事可以做：

分析问题。每日摘要邮件不包含有关实际故障的详细信息：为了查看发生了什么，您必须打开构建日志并检查最后的输出。让某人为邮件中的所有包执行此操作对于其他开发人员非常有用，因为他们可以仅基于此输出进行快速初始分析。
解决问题。修复autobuild失败时，您应该按照以下步骤操作：

检查是否可以通过使用相同配置构建来重现问题。您可以手动执行此操作，或使用 br-reproduce-build 脚本自动克隆Buildroot git存储库，检出正确的修订版，下载并设置正确的配置，然后启动构建。
分析问题并创建修复程序。
通过从干净的Buildroot树开始并仅应用您的修复，验证问题是否已得到解决。
将修复程序发送到Buildroot邮件列表（请参见 第21.5节“提交修补程序”）。如果您针对包源创建了修补程序，则还应该向上游发送修补程序，以便在以后的版本中修复该问题，并且可以删除Buildroot中的修补程序。在修复autobuild失败的补丁的提交消息中，添加对构建结果目录的引用，如下所示：
修复http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
21.3。查看和测试补丁
随着每天发送到邮件列表的补丁数量，维护者很难判断哪些补丁准备好应用，哪些补丁不准备。通过审查和测试这些补丁，贡献者可以在这方面提供很大帮助。

在审核过程中，请毫不犹豫地回复提交补丁，提供评论，建议或任何有助于每个人理解补丁并使其更好的内容。在回复提交补丁时，请在纯文本电子邮件中使用互联网样式回复。

为了表明批准补丁，有三个正式标记可以跟踪此批准。要将标记添加到修补程序，请使用原始作者的签名越线下方的批准标记回复该标记。这些标签将通过拼凑自动拾取（请参见 第21.3.1节“从拼布中应用补丁”），并且在接受补丁时将成为提交日志的一部分。

经测试通过
表示补丁已成功测试。建议您指定执行的测试类型（对体系结构X和Y进行编译测试，对目标A进行运行时测试，…）。这些附加信息可以帮助其他测试人员和维护人员。
来自逐
表示您对补丁进行了代码审查，并尽力发现问题，但您并不熟悉触及的区域以提供Acked-by标记。这意味着补丁中可能存在剩余问题，这些问题将由在该领域具有更多经验的人发现。如果检测到此类问题，您的评论标签仍然适用，您不能受到指责。
ACKED逐
表示您对补丁进行了代码审查，并且您对所触及的区域非常熟悉，感觉补丁可以按原样提交（无需进行其他更改）。如果它后来证明补丁有问题，你的Acked-by可能被认为是不合适的。因此，Acked-by和Review-by之间的区别主要在于您准备将责任归咎于Acked补丁，而不是被评估的补丁。
如果您查看了修补程序并对其进行了评论，则只需回复说明这些注释的修补程序，而无需提供“已审阅”或“已确认”标记。只有在您判断补丁是否良好时，才应提供这些标记。

值得注意的是，Review-by和Acked-by都没有暗示已经进行了测试。为了表明您已经审核并测试了补丁，请提供两个单独的标记（已审核/已执行和已测试）。

另请注意，任何开发人员都可以毫无例外地提供经过测试/已审核/已确认的标记，我们鼓励大家这样做。Buildroot没有一组定义的核心开发人员，只是有些开发人员比其他人更活跃。维护者将根据其提交者的跟踪记录来评估标签。由常规贡献者提供的标签自然比新人提供的标签更受信任。当您更频繁地提供标签时，您的 可信度（在维护者眼中）会上升，但所 提供的任何标签都是有价值的。

Buildroot的Patchwork网站可用于提供补丁以用于测试目的。有关使用Buildroot的Patchwork网站应用补丁的更多信息，请参见第21.3.1节“从拼凑中应用补丁”。

21.3.1。从拼布中应用补丁
Buildroot的Patchwork网站对开发人员的主要用途是将补丁纳入其本地git存储库以进行测试。

在拼凑管理界面中浏览补丁时，mbox 页面顶部会提供一个链接。复制此链接地址并运行以下命令：

$ git checkout -b
$ wget -O - | 我是
应用补丁的另一个选择是创建一个包。捆绑包是一组补丁，您可以使用拼凑界面将它们组合在一起。创建捆绑包并将捆绑包公开后，您可以复制mbox捆绑包的链接并使用上述命令应用捆绑包。

21.4。处理TODO列表中的项目
如果您想为Buildroot做贡献但不知道从哪里开始，并且您不喜欢上述任何主题，您可以随时处理Buildroot TODO列表中的项目。不要犹豫，先在邮件列表或IRC上讨论一个项目。编辑维基以指示您何时开始处理某个项目，因此我们避免重复工作。

21.5。提交补丁
注意
请不要将补丁附加到错误，而是将它们发送到邮件列表。

如果您对Buildroot进行了一些更改，并且希望将它们贡献给Buildroot项目，请按以下步骤操作。

21.5.1。补丁的格式
我们希望以特定方式格式化补丁。这是必要的，以便能够轻松查看补丁，以便能够轻松地将它们应用到git存储库，以便于在历史记录中找回事情发生变化的方式和原因，并且可以使用它git bisect来定位补丁。问题的根源。

首先，补丁必须具有良好的提交消息。提交消息应该以一个单独的行开头，其中包含更改的简短摘要，从受影响的包的名称开始。提交消息的主体应描述为什么需要进行此更改，并在必要时还提供有关如何完成此更改的详细信息。在编写提交消息时，请考虑审阅者如何阅读它，还要考虑在几年后再次查看此更改时如何阅读它。

其次，补丁本身应该只进行一次更改，但要完全完成。通常应在两个单独的补丁中进行两个不相关或弱相关的更改。这通常意味着补丁仅影响单个包。如果多个更改相关，通常仍然可以将它们拆分为小补丁并按特定顺序应用它们。小补丁使查看更容易，并且通常可以更容易理解为什么要进行更改。但是，每个补丁必须完整。当仅应用第一个补丁而不是第二个补丁时，不允许构建被破坏。这是必要的，以便能够在git bisect之后使用。

当然，在进行开发时，你可能会在软件包之间来回切换，当然也不会立即以足够干净的方式提交。因此，大多数开发人员都会重写提交历史记录，以生成一组适合提交的简洁提交。为此，您需要使用交互式变基。您可以在Pro Git书中了解它 。有时，git reset --soft origin/master使用git add -i或选择单个更改 甚至更容易丢弃历史记录 git add -p。

最后，应该签署补丁。这是通过在提交消息的末尾添加来完成的 。如果配置正确，为您做到这一点。的标签意味着你发布下Buildroot里面许可证贴片（即GPL-2.0 +，除了包贴剂，其具有上游许可），并且您允许这样做。有关详细信息，请参阅Developer Origin of Origin。Signed-off-by: Your Real Name [email protected] commit -sSigned-off-by

添加新软件包时，您应该在单独的修补程序中提交每个软件包。此修补程序应包含对 package/Config.in程序包Config.in文件，.mk文件， .hash文件，任何init脚本和所有程序包修补程序的更新。如果包有许多子选项，有时可以更好地添加这些子选项作为单独的后续补丁。摘要行应该是这样的 : new package。对于简单包，提交消息的主体可以为空，也可以包含包的描述（如Config.in帮助文本）。如果需要做任何特殊的事情来构建包，那么这也应该在提交消息体中明确解释。

将包打包到新版本时，还应为每个包提交单独的修补程序。不要忘记更新.hash 文件，如果文件尚不存在则添加。另外不要忘了检查_LICENSE，并_LICENSE_FILES仍然有效。摘要行应该是这样的: bump to version 。如果新版本仅包含与现有版本相比的安全更新，则摘要应为: security bump to version ，并且提交消息正文应显示已修复的CVE编号。如果可以在新版本中删除某些软件包修补程序，则应明确说明可以删除它们的原因，最好使用上游提交ID。此外，还应明确说明任何其他必需的更改，例如不再存在或不再需要的配置选项。

如果您有兴趣收到构建失败的通知以及您添加或修改的软件包的进一步更改，请将您自己添加到DEVELOPERS文件中。这应该在创建或修改包的同一补丁中完成。有关 更多信息，请参阅DEVELOPERS文件 第22章，DEVELOPERS文件和get-developers。

Buildroot提供了一个方便的工具来检查您创建或修改的文件的常见编码样式错误check-package（称为更多信息，请参见 第17.23.2节“如何检查编码样式”）。

21.5.2。准备补丁系列
从承诺在您的本地git的看法的变化入手，变基 生成补丁集之前，对上游树的顶端的开发分支。为此，请运行：

$ git fetch --all --tags
$ git rebase origin / master
现在，您已准备好生成然后提交补丁集。

要生成它，请运行：

$ git format-patch -M -n -s -o outgoing origin / master
这将在outgoing子目录中生成补丁文件，自动添加该Signed-off-by行。

生成补丁文件后，您可以使用您喜欢的文本编辑器在提交之前查看/编辑提交消息。

Buildroot提供了一个方便的工具，可以知道应该向谁发送补丁get-developers（称为更多信息，请参阅第22章，DEVELOPERS文件和get-developers）。此工具读取您的补丁并输出git send-email要使用的相应 命令：

$ ./utils/get-developers outgoing / *
使用输出get-developers发送补丁：

$ git send-email --to [email protected] --cc bob --cc alice outgoing / *
请注意，git应配置为使用您的邮件帐户。配置git，查看man git-send-email或谷歌。

如果您不使用git send-email，请确保已发布的补丁不是换行的，否则无法轻松应用。在这种情况下，修复您的电子邮件客户端，或者更好，学会使用git send-email。

21.5.3。求职信
如果要在单独的邮件中显示整个修补程序集，请添加 --cover-letter到git format-patch命令（man git-format-patch有关详细信息，请参阅参考资料）。这将为您的补丁系列生成介绍电子邮件的模板。

一个求职信向您介绍在下列情况下提出的修改可能有用：

该系列中有大量的提交;
项目其余部分变化的深刻影响;
RFC [4] ;
只要您觉得它有助于展示您的工作，您的选择，审核流程等。
21.5.4。补丁修订更改日志
当请求改进时，每个提交的新修订应包括每个提交之间的修改的更改日志。请注意，当您通过求职信引入补丁系列时，除了各个提交中的更改日志之外，还可以在求职信中添加整体更改日志。修改补丁系列的最好方法是通过交互式变基： git rebase -i origin/master。有关更多信息，请参阅git手册。

添加到单个提交时，在编辑提交消息时会添加此更改日志。在该Signed-off-by部分下方，添加 —和您的更改日志。

尽管更改日志对于邮件线程中的审阅者以及拼凑而言都是可见的，但是当合并补丁时，git 将自动忽略下面—的行。这是预期的行为：更改日志并不意味着永远保留在git项目的历史记录中。

此后推荐的布局：

补丁标题：简短说明，最多72个字符

一个解释问题的段落，以及它如何表现出来。如果
问题很复杂，可以添加更多段落。所有段落
应该包含72个字符。

一段解释问题根本原因的段落。再一次，更多
比段落还可以。

最后，一个或多个段落解释了问题是如何解决的。
不要犹豫，详细解释复杂的解决方案。

签名：John DOE [email protected]

---

更改v2 - > v3：

• foo bar（Jane建议）
• 酒吧buz

更改v1 - > v2：

• alpha bravo（John建议）
• 查理三角洲
  任何修补程序修订版都应包含版本号。版本号简单地由字母v后跟integer大于或等于2 的字母组成（即“PATCH v2”，“PATCH v3”…）。

git format-patch使用选项 可以轻松处理–subject-prefix：

$ git format-patch --subject-prefix“PATCH v4”
-M -s -o out origin / master
从git版本1.8.1开始，你也可以使用-v （其中是版本号）：

$ git format-patch -v4 -M -s -o outgoing origin / master
当您提供补丁的新版本时，请将旧版本标记为拼凑而成。您需要在拼凑上创建一个帐户才能修改补丁的状态。请注意，您只能更改自己提交的修补程序的状态，这意味着您在拼凑中注册的电子邮件地址应与用于将修补程序发送到邮件列表的地址相匹配。

您还–in-reply-to 可以在向邮件列表提交补丁时添加该选项。要回复的邮件的ID可以在拼凑的“Message Id”标签下找到 。回复的优点 是拼凑会自动将补丁的先前版本标记为已取代。

21.6。报告问题/错误或获得帮助
在报告任何问题之前，请检查 邮件列表存档 第5章，社区资源是否有人已经报告和/或修复了类似的问题。

但是，您可以通过在错误跟踪器 第5章，社区资源中打开错误或通过 向邮件列表发送邮件来 选择报告错误或获取帮助。第5 章，社区资源，有许多细节要提供，以便帮助人们重现并找到问题的解决方案。

试着想想你是在试图帮助别人; 在那种情况下，你需要什么？

以下是在这种情况下提供的详细信息的简短列表：

主机（OS /发布）
Buildroot的版本
构建失败的目标
构建失败的软件包
失败的命令及其输出
您认为可能相关的任何信息
此外，您应该添加该.config文件（或者如果您知道如何，a defconfig;请参见第9.3节“存储Buildroot配置”）。

如果其中一些细节太大，请不要犹豫，使用pastebin服务。请注意，下载原始粘贴时，并非所有可用的pastebin服务都会保留Unix样式的行终止符。已知以下pastebin服务可以正常工作： - https://gist.github.com/ - http://code.bulix.org/

[4] RFC :(征求意见）改变提案

第22章开发人员文件和获取开发人员
主Buildroot目录包含一个名为的文件DEVELOPERS，列出了涉及Buildroot各个领域的开发人员。多亏了这个文件，该get-developer工具允许：

通过解析补丁并将修改后的文件与相关开发人员进行匹配，计算应向其发送补丁的开发人员列表。有关详细信息，请参见第21.5节“提交补丁”。
查找哪些开发人员正在处理给定的体系结构或程序包，以便在此体系结构或程序包发生构建失败时通知他们。这是在与Buildroot的autobuild基础设施交互时完成的。
我们要求开发人员在Buildroot中添加新软件包，新电路板或一般新功能，以便在DEVELOPERS 文件中注册自己。作为一个例子，我们希望开发人员提供一个新的包，在他的补丁中包含对DEVELOPERS文件的适当修改 。

该DEVELOPERS文件格式的文件本身里面详细记录。

该get-developer工具位于utils/允许将DEVELOPERS文件用于各种任务：

当传递一个或多个补丁作为命令行参数时， get-developer将返回相应的git send-email 命令。
使用-a 命令行选项时，get-developer将返回负责给定体系结构的开发人员列表。
使用-p 命令行选项时，get-developer 将返回负责给定包的开发人员列表。
使用-c命令行选项时，get-developer将查看Buildroot存储库中版本控制下的所有文件，并列出任何开发人员未处理的文件。此选项的目的是帮助完成DEVELOPERS文件。
在没有任何参数的情况下使用时，它会验证DEVELOPERS文件的完整性，并会为不匹配的项目记录警告。
第四部分。附录
第23章Makedev语法文档
makedev语法在Buildroot中的几个位置用于定义对权限所做的更改，或者要创建哪些设备文件以及如何创建它们，以避免调用mknod。

此语法派生自makedev实用程序，可在package/makedevs/README文件中找到更完整的文档。

它采用空格分隔的字段列表的形式，每行一个文件; 这些领域是：

名称

类型

模式

UID

GID

重大的

次要

开始

INC

计数

有一些非平凡的块：

name 是要创建/修改的文件的路径
type 是文件的类型，是以下之一：

f：常规文件
d：目录
r：递归目录
c：字符设备文件
b：块设备文件
p：命名管道
mode 是通常的权限设置（只允许数值）
uid并且gid是要在此文件上设置的UID和GID; 可以是数值或实际名称
major并minor在这里为设备文件设置为-其它文件
start，inc并且count适用于何时想要创建一批文件，并且可以缩减为循环，从开始start，递增计数器inc直到达到count
假设您要更改给定文件的权限; 使用这种语法，你需要写：

/ usr / bin / foo f 755 0 0 - - - - -
/ usr / bin / bar f 755 root root - - - - -
/ data / buz f 644 buz-user buz-group - - - - -
或者，如果要以递归方式更改目录的所有者/权限，则可以编写（将UID设置为foo，将GID设置为bar以及对rwxr-x的访问权限 - 对于目录/ usr / share / myapp和所有文件它下面的目录）：

/ usr / share / myapp r 750 foo bar - - - - -
另一方面，如果要/dev/hda 为分区创建设备文件和相应的15个文件，则需要 /dev/hda：

/ dev / hda b 640 root root 3 0 0 0 -
然后对对应于分区的设备文件 /dev/hda，/dev/hdaX，X范围从1到15：

/ dev / hda b 640 root root 3 1 1 1 15
如果BR2_ROOTFS_DEVICE_TABLE_SUPPORTS_EXTENDED_ATTRIBUTES启用，则支持扩展属性 。这是通过|xattr在描述文件的行之后添加一行来完成的。目前，只支持功能作为扩展属性。

| XATTR

能力

|xattr 是一个表示扩展属性的“标志”
capability 是添加到上一个文件的功能
如果要将功能cap_sys_admin添加到二进制文件foo，您将编写：

/ usr / bin / foo f 755 root root - - - - -
| xattr cap_sys_admin + eip
您可以使用多|xattr行向文件添加多个功能。如果要将功能cap_sys_admin和cap_net_admin添加到二进制文件foo，您将编写：

/ usr / bin / foo f 755 root root - - - - -
| xattr cap_sys_admin + eip
| xattr cap_net_admin + eip
第24章Makeusers语法文档
创建用户的语法受上面的makedev语法的启发，但特定于Buildroot。

添加用户的语法是以空格分隔的字段列表，每行一个用户; 这些领域是：

用户名

UID

组

GID

密码

家

贝壳

组

评论

哪里：

username是用户所需的用户名（也称为登录名）。它不可能root，而且必须是唯一的。如果设置为-，则只创建一个组。
uid是用户所需的UID。它必须是独一无二的，而不是 0。如果设置为-1，则Buildroot将在[1000 … 1999]范围内计算唯一的UID
group是用户主要组的所需名称。它不可能root。如果该组不存在，则将创建该组。
gid是用户主要组的所需GID。它必须是独一无二的，而不是0。如果设置为-1，并且该组尚不存在，则Buildroot将在[1000…1999]范围内计算唯一的GID
password是crypt（3）编码的密码。如果带有前缀!，则禁用登录。如果带有前缀=，则将其解释为明文，并将进行加密编码（使用MD5）。如果带有前缀 !=，则密码将被加密编码（使用MD5）并且将禁用登录。如果设置为*，则不允许登录。如果设置为 -，则不会设置密码值。
home是用户所需的主目录。如果设置为-，则不会创建主目录，并且用户的主页将是/。不允许明确设置home为/。
shell是用户所需的shell。如果设置为-，则将 /bin/false其设置为用户的shell。
groups是用户应该参与的其他组的逗号分隔列表。如果设置为-，则用户将成为无其他组的成员。将使用任意方式创建缺少的组 gid。
comment（又名GECOS 字段）是一种几乎自由形式的文本。
每个字段的内容都有一些限制：

除了comment，所有字段都是强制性的。
除了comment，字段可能不包含空格。
没有字段可能包含冒号（:）。
如果home不是-，则主目录和下面的所有文件将属于用户及其主要组。

例子：

foo -1 bar -1！= blabla / home / foo / bin / sh alpha，bravo Foo用户
这将创建此用户：

username （又名登录名）是： foo
uid 由Buildroot计算
主要group是：bar
主要组gid由Buildroot计算
明文password是：blabla，将是crypt（3） - 编码，并且禁用登录。
home 是： /home/foo
shell 是： /bin/sh
foo也是groups：alpha和。的成员bravo
comment 是： Foo user
test 8000 wheel -1 = - / bin / sh - 测试用户
这将创建此用户：

username （又名登录名）是： test
uid 是： 8000
主要group是：wheel
main组gid由Buildroot计算，并将使用rootfs骨架中定义的值
password 是空的（也就是没有密码）。
home是/，但将不属于test
shell 是： /bin/sh
test 不是任何其他成员 groups
comment 是： Test user
第25章从旧的Buildroot版本迁移
某些版本引入了向后不兼容性。本节介绍了这些不兼容性，并分别解释了如何完成迁移。

25.1。迁移到2016.11
在Buildroot 2016.11之前，可以一次只使用一个br2外部树。使用Buildroot 2016.11可以同时使用多个（有关详细信息，请参见第9.2节“在Buildroot之外保留自定义”）。

然而，这意味着较旧的br2外部树不能按原样使用。必须进行微小的更改：为br2外部树添加名称。

只需几个步骤即可轻松完成此操作：

首先，external.desc在br2外部树的根目录下创建一个名为br2-external树名称的单行的新文件：

$ echo’name：NAME_OF_YOUR_TREE’> external.desc
注意。 选择名称时要小心：它必须是唯一的，并且只能使用集合中的ASCII字符[A-Za-z0-9_]。

然后，BR2_EXTERNAL使用新变量更改br2外部树中的每个出现：

$ find。-type f | xargs sed -i’s / BR2_EXTERNAL / BR2_EXTERNAL_NAME_OF_YOUR_TREE_PATH / g’
现在，您的br2外部树可以与Buildroot 2016.11一起使用。

注意： 此更改使您的br2外部树在2016.11之前与Buildroot不兼容。

25.2。迁移到2017.08
在Buildroot 2017.08之前，安装了主机软件包$(HOS{T}_{D}IR)/usr（例如autotool{s}^{\prime }--prefix=$(HOST_DIR)/usr）。使用Buildroot 2017.08，它们现在直接安装在$(HOST_DIR)。

每当程序包安装与库中链接的可执行文件时$(HOST_DIR)/lib，它必须具有指向该目录的RPATH。

指向的RPATH $(HOST_DIR)/usr/lib不再被接受。