Buildroot用户手册

Buildroot用户手册

目录
Buildroot用户手册 1
第一部分 6
第1章关于Buildroot 7
第二章系统要求 7
2.1.强制包裹 8
2.2。可选包 9
第3章获取Buildroot 10
第4章Buildroot快速入门 11
第五章社区资源 15
第二部分。用户指南 17
第6章Buildroot配置 17
6.1.交叉编译工具链 18
6.1.1.内部工具链后端 19
6.1.2.外部工具链后端 21
6.2。/ dev管理 24
6.3。init系统 27
第七章其他组件的配置 29
第8章常规Buildroot用法 31
8.1。 做提示 31
8.2.了解何时需要完全重建 35
8.3.知道如何重建包 37
8.4。离线构建 38
8.5.建在树外 39
8.6。环境变量 40
8.7.有效处理文件系统的图像 41
8.8.绘制包之间的依赖关系 43
8.9.绘制结构的持续时间 45
8.10.绘制包文件系统大小贡献图 46
8.11。与Eclipse集成 48
8.12。高级用法 49
8.12.1。使用Buildroot外部生成的工具链 49
8.12.2。gdb在Buildroot中使用 49
8.12.3。ccache在Buildroot中使用 51
8.12.4.下载包的位置 53
8.12.5.特定于包的生产目标 53
8.12.6.在开发过程中使用Buildroot 54
第九章特定于项目的自定义 57
9.1.推荐的目录结构 59
9.1.1.实现分层自定义 61
9.2。在Buildroot保留自定义 62
9.2.1。br2外树布局 64
9.3。存储Buildroot配置 74
9.4.存储其他组件的配置 74
9.5.自定义生成的目标文件系统 76
9.5.1.设置文件权限和所有权，并添加自定义设备节点 80
9.6.添加自定义用户账户 81
9.7。创建图像后的自定义 82
9.8.添加项目特定的维修程序 83
9.9.添加特定于项目的包 85
9.10.存储项目具体定制的快速指南 86
第十章常见问题及故障排除 89
10.1.启动网络后，启动并挂起… 89
10.2.为什么目标上没有编译器？ 90
10.3.为什么目标上没有开发文件？ 91
10.4.为什么目标没有文档？ 91
10.5。为什么在Buildroot有些包在配置菜单中看不见？ 91
10.6.为什么不用目标目录？chroot目录？ 92
10.7。为什么Buildroot不生成二进制包（.deb，.ipkg …）？ 92
10.8.如何加快施工过程？ 95
第一章。已知问题 96
第十二章法律声明和许可 97
12.1。遵守开源许可证 97
12.2。遵守Buildroot许可证 99
12.2.1。补丁包 100
第13章超越Buildroot 100
13.1.引导生成的图像 100
13.1.1。NFS启动 100
13.1.2。Live CD 101
13.2。chroot环境 102
第三部分。开发者指南 102
第14章Buildroot的工作原理 102
第15章编码风格 104
15.1。 Config.in文件 104
15.2。该.mk文件 105
15.3。文档 108
15.4。支持脚本 109
第16章。增加对特定板的支持 109
第17章向Buildroot添加新包 110
17.1。包目录 110
17.2。配置文件 111
17.2.1。 Config.in文件 111
17.2.2。 Config.in.host文件 112
17.2.3。选择depends on或select 113
17.2.4.依赖目标和工具链选项 117
17.2.5。依赖于buildroot构建的Linux内核 121
17.2.6。对udev / dev管理的依赖 122
17.2.7.依赖虚拟包提供的功能 122
17.3。该.mk文件 123
17.4。该.hash文件 124
17.5.具有特定建筑系统的包的基础结构 128
17.5.1。 generic-package教程 128
17.5.2。 generic-package参考 135
17.6。基于autotools软件包的基本结构 148
17.6.1。 autotools-package教程 148
17.6.2。 autotools-package参考 151
17.7。基于CMake软件包的基本结构 154
17.7.1。 cmake-package教程 154
17.7.2。 cmake-package参考 157
17.8。Python包的基础结构 160
17.8.1。 python-package教程 160
17.8.2。 python-package参考 162
17.8.3。python-package从PyPI存储库生成a 166
17.8.4。 python-packageCFFI后端 167
17.9。基于LuaRocks软件包的基本结构 169
17.9.1。 luarocks-package教程 169
17.9.2。 luarocks-package参考 171
17.10。Perl / CPAN包的基础结构 172
17.10.1。 perl-package教程 172
17.10.2。 perl-package参考 175
17.11.虚拟包的基础结构 177
17.11.1。 virtual-package教程 177
17.11.2。虚拟包的Config.in文件 178
17.11.三节。虚拟包.mk文件 178
17.11.4。提供者的Config.in文件 179
17.11.5。提供者的.mk文件 180
17.11.6.依赖虚拟包的注意事项 181
17.11.7.具体提供商的说明取决于具体提供商的说明。 181
17,12。使用kconfig软件包配置文件的基础结构 182
17.13.基于螺纹钢包装的基础设施 185
17.13.1。 rebar-package教程 185
17.13.2。 rebar-package参考 186
17.14。基于Waf软件包的基本结构 188
17.14.1。 waf-package教程 188
17.14.2。 waf-package参考 190
17.15。基于Meson包的基础结构 191
17.15.1。 meson-package教程 191
17.15.2。 meson-package参考 194
17.16.基于货物的包裹集成 195
17.16.1.基于货物的包裹Config.in文件 195
17.16.2。基于货物的包裹的.mk文件 196
17.16.3.关于依赖关系管理 199
17.17。Go包的基础设施 200
17.17.1。 golang-package教程 200
17.17.2。 golang-package参考 201
17.18.构建内核模块包的基础结构 204
17.18.1。 kernel-module教程 204
17.18.2。 kernel-module参考 208
17.19。asciidoc文档的基本结构 210
17.19.1。 asciidoc-document教程 210
17.19.2。 asciidoc-document参考 212
17.20。特定于Linux内核包的基本结构 215
17.20.1。Linux内核工具 215
17.20.2。Linux内核的扩展 219
17.21.钩子可用于各种施工步骤 221
17.21.1。使用POST_RSYNC钩子 223
17.21.2。Target-finalize钩子 223
17.22。Gettext集成与包的交互 223
17.23.技巧和技巧 225
17.23.1.包名，配置项名和makefile变量关系 225
17.23.2.如何检查编码风格？ 226
17.23.3.如何测试你的包裹？ 227
17.23.4。如何从GitHub添加包 230
17.24。结论 232
第18章修补包 232
18.1。提供补丁 233
18.1.1。下载 233
18.1.2。在Buildroot内 233
18.1.三、全局补丁目录 234
18.2.如何使用补丁？ 234
18.3.包修程序的格式和许可 235
18.4。集成Web上的补丁 237
第十九章下载基础结构 238
第20章调试Buildroot 238
第21章。对Buildroot的贡献 239
21.1.重现、分析和修复错误 240
21.2.分析修复autobuild故障 240
21.3.检查和测试补丁 242
21.3.1.补丁应用于拼布 244
21.4。处理TODO列表中的项目 245
21.5。提交补丁 245
注意 245
21.5.1.补丁格式 245
21.5.2.准备补丁系列 248
21.5.3。求职信 249
21.5.4.修改补丁，更改日志。 250
21.6.报告问题/错误或帮助 252
第二十二章开发人员文件和开发人员 253
第四部分 255
第23章Makedev语法文档 255br> 第24章Makeusers语法文档 258
第25章从旧的Buildroot版本迁移 261
25.1。迁移到2016.11 261
25.2。迁移到2017.08 263

实例清单
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开发人员

第一部分。入门
第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。强制性包裹
• 构建工具：
o which
o sed
o make （版本3.81或更高版本）
o binutils
o build-essential （仅适用于基于Debian的系统）
o gcc （4.4版或更高版本）
o g++ （4.4版或更高版本）
o bash
o patch
o gzip
o bzip2
o perl （版本5.8.7或更高版本）
o tar
o cpio
o python （2.6或更高版本）
o unzip
o rsync
o file（必须在/usr/bin/file）
o bc
• 源提取工具：
o wget
2.2。可选包
• 配置接口依赖项：
对于这些库，您需要同时安装运行时和开发数据，这些数据在许多发行版中是单独打包的。开发包通常具有-dev或-devel后缀。
o ncurses5使用menuconfig界面
o qt4使用xconfig接口
o glib2，gtk2并glade2使用gconfig接口
• 源提取工具：
在官方的树，大部分包源通过使用检索 wget从FTP，HTTP或HTTPS位置。一些软件包只能通过版本控制系统获得。此外，Buildroot能够通过其他工具下载源，如rsync或scp （有关更多详细信息，请参阅第19章，下载基础结构）。如果使用上述任何方法启用软件包，则需要在主机系统上安装相应的工具：
o bazaar
o cvs
o git
o mercurial
o rsync
o scp
o subversion
• 与Java相关的包，如果需要为目标系统构建Java Classpath：
o 该javac编译器
o 该jar工具
• 文档生成工具：
o asciidoc，版本8.6.3或更高版本
o w3m
o python使用argparse模块（自动出现在2.7+和3.2+）
o dblatex （仅限pdf手册）
• 图生成工具：
o graphviz使用graph-depends和 -graph-depends
o 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 只有在内部工具链后端选择了uClibc C库时才可用;
• barebox-menuconfig并且barebox-savedefconfig仅在barebox启用引导加载程序时有效 。
• uboot-menuconfig并且uboot-savedefconfig仅在U-Boot启用引导加载程序时有效 。
清理： 更改任何体系结构或工具链配置选项时，需要进行明确清除。
要删除所有构建产品（包括构建目录，主机，登台和目标树，图像和工具链）：
$ make clean
生成手册： 本手册源位于docs / manual目录中。要生成手册：
$ make manual-clean
$ make manual
手动输出将在output / docs / manual中生成。
笔记
• 构建文档需要一些工具（参见： 第2.2节“可选包”）。
为新目标重置Buildroot： 删除所有构建产品以及配置：
$ make distclean
笔记。 如果ccache已启用，则运行make clean或distclean不清空Buildroot使用的编译器缓存。要删除它，请参见第8.12.3节“ ccache在Buildroot中使用”。
转储内部make变量： 可以转储已知的所有变量及其值：
$ make -s printvars
VARIABLE= value_of_variable
…
可以使用一些变量调整输出：
• VARS 将列表限制为与指定的make-pattern匹配的变量
• QUOTED_VARS，如果设置为YES，将单引号
• RAW_VARS，如果设置为YES，将打印未展开的值
例如：
$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES
BUSYBOX_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_ALL_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_PATCH_DEPENDENCIES=
BUSYBOX_RDEPENDENCIES=ncurses util-linux
$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES QUOTED_VARS=YES
BUSYBOX_DEPENDENCIES=‘skeleton toolchain’
BUSYBOX_FINAL_ALL_DEPENDENCIES=‘skeleton toolchain’
BUSYBOX_FINAL_DEPENDENCIES=‘skeleton toolchain’
BUSYBOX_FINAL_PATCH_DEPENDENCIES=’’
BUSYBOX_RDEPENDENCIES=‘ncurses util-linux’
$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES RAW_VARS=YES
BUSYBOX_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_ALL_DEPENDENCIES=$(sort $(BUSYBOX_FINAL_DEPENDENCIES) $(BUSYBO{X}_{F}INA{L}_{P}ATC{H}_{D}EPENDENCIES))BUSYBO{X}_{F}INA{L}_{D}EPENDENCIES=$(sort $(BUSYBO{X}_{D}EPENDENCIES))BUSYBO{X}_{F}INA{L}_{P}ATC{H}_{D}EPENDENCIES=$(sort $(BUSYBOX_PATCH_DEPENDENCIES))
BUSYBOX_RDEPENDENCIES=ncurses util-linux
引用变量的输出可以在shell脚本中重用，例如：
$ eval $(make -s printvars VARS=BUSYBOX_DEPENDENCIES QUOTED_VARS=YES)
$ echo $BUSYBOX_DEPENDENCIES
skeleton toolchain
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选项告诉它只存储非零的稀疏文件块：
o tar cf archive.tar -S [files…] 将有效地存储tarball中的稀疏文件
o tar xf archive.tar -S 将有效地存储从tarball中提取的稀疏文件
• cp接受该–sparse=WHEN选项（WHEN是一个auto， never或always）：
o 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文件，详细说明不同软件包的大小贡献。
要在构建后生成这些数据，请运行：
make graph-size
这将产生：
• output/graphs/graph-size.pdf，每个包对总体根文件系统大小的贡献的饼图
• output/graphs/package-size-stats.csv，CSV文件，将每个包的大小贡献分配给整个根文件系统大小
• output/graphs/file-size-stats.csv，一个CSV文件，它将每个已安装文件的大小