8. Buildroot用户手册-Buildroot的一般用法

转载请注明原文链接：https://blog.csdn.net/haimo_free/article/details/107677667

8. Buildroot的一般用法

8.1 make技巧

这是一系列技巧，可以帮助你充分利用Buildroot。

显示make执行的所有命令：

make V=1 <target>

显示所有带默认配置的目标板列表：

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引导加载程序启用时有效

清理： 当CPU体系架构或工具链配置选项更改时，都需要显式清理。要删除所有构建产物（包括output/build/、output/host、output/staging和output/target/等目录及系统镜像和工具链等）：

make clean

生成用户手册： 用户手册源文档位于docs/manual目录，生成的手册位于output/docs/manual。

make manual-clean
make manual

注意，生成文档需要某些工具（参阅第2.2节“可选软件包”）。

重置Buildroot： 删除所有构建产物，包括配置文件：

make distclean

注意，如果启用缓存，运行make clean或make distclean不会清空该缓存。要删除它，请参阅第8.13.3节“在Buildroot中使用缓存”。

转储内部make变量： 可以转储已知的make变量，以及值。

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

可以使用一些变量来调整输出：

• VARS 仅输出与make-patterns匹配的变量，必须设置此变量，否则不打印任何内容
• 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) $(BUSYBOX_FINAL_PATCH_DEPENDENCIES))
 BUSYBOX_FINAL_DEPENDENCIES=$(sort $(BUSYBOX_DEPENDENCIES))
 BUSYBOX_FINAL_PATCH_DEPENDENCIES=$(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 了解何时需要完全重新构建

当通过meke menuconfig、make xconfig或其他配置工具修改系统配置时，Buildroot不会尝试去检测系统的哪些部分需要重新构建。在某些情况下，Buildroot应该重新构建整个系统，在某些情况下，仅需重新构建某个软件包的特定子集。但是，完全可靠的检测到这些非常困难，因此Buildroot开发人员决定不尝试这么做。

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

• 当目标体系结构配置改变时，需要完全重建。例如，更改CPU体系结构、二进制格式或浮点数策略会对整个系统产生影响。
• 当更改编译工具链配置时，通常需要完全重建。更改工具链配置通常涉及更改编译器版本、C库类型及其配置，或者其他一些基本配置项，这些更改会影响整个系统。
• 添加软件包到配置中时，不一定需要完全重建。Buildroot会检测到从未构建过该软件包，并对其进行构建。但是，如果此软件包是其他已构建的软件包的可选择性使用的依赖项时，Buildroot不会自动重新构建它们。如果你知道需要重建哪些软件包，那么可以手动重建它们，否则你需要进行完全重建。假设，你使用ctorrent包构建了一个系统，但是没有openssl库。你的系统可以运行，但是你意识到希望ctorrent支持SSL，因此你在Buildroot中勾选了openssl并重新开始构建。Buildroot将检测到openssl应该构建并构建它，但是它不会检测到ctorrent应该重新构建以支持openssl。你需要完全重新构建，或者仅重新构建ctorrent。
• 从配置中删除软件包时，Buildroot不会执行任何特殊操作。它不会从根文件系统或工具链sysroot中删除该软件包安装的文件。若要摆脱该软件包需要完全重建才行。但是，通常你不必立即删除该软件包，可以等到休息时再完全重建。
  更改软件包的选项时，该软件包不会自动重建。进行此类更改后，通常仅重建该软件包就足够了，除非启用的选项会向该软件包添加一些功能，而这些功能对于已构建的另一个软件包很有用。同样，Buildroot不会跟踪何时应该重建软件包，一旦构建了软件包，就不会对其进行重新构建，除非明确要求这么做。
• 更改文件系统格式后，需要完全重建。然而，如果是更改根文件系统的覆盖文件，post-build或post-image脚本将会执行，此时没有必要完全重建，简单的make即可。
• 如果FOO_DEPENDENCIES列出的软件包重新构建或移除，foo软件包不会自动重新构建。例如，如果foo依赖软件包bar，即FOO_DEPENDENCIES=bar，当软件包bar的配置更改时，foo不会自动重新构建。在这种情况下，你可能需要重新构建所有引用bar的软件包，或者完全重建以确保所有依赖bar的相关软件包都是最新的。

一般而言，当你遇到构建错误，并且不确定所做的配置更改可能带来的后果时，请完全重建。如果你还是遇到相同的构建错误，则可以确定该错误与软件包的部分重建无关，如果该错误发生在Buildroot的官方构建包中，请立即反馈该问题。随着你对Buildroot的了解加深，你将逐步了解何时真正需要进行完全重建，并且可以节省越来越多的时间。

作为参考，可以通过运行以下命令来进行完全重建：

make clean all

8.3 了解如何重新构建软件包

Buildroot用户提出的最常见的问题之一是如何重建给定的软件包，或如何删除软件包而无需重新构建所有内容。

Buildroot不支持不重新构建的情况下删除软件包。这是因为Buildroot不会跟踪哪个软件包在output/staging和output/target目录中安装了哪些文件，或者哪个软件包将根据另一个软件包的可用性进行不同的编译。

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

另一方面，如果你只想从编译步骤重新开始软件包的构建过程，则可以运行make -rebuild命名。这将重新开始编译和安装该软件包，它基本上是在软件包内重新执行make和make install命令，所以，它只会重新编译更改过的文件。

如果你想从配置步骤重新开始软件包的构建过程，则可以运行make -reconfigure命令，它将重新配置、编译和安装该软件包。

尽管-rebuild隐含-reinstall并且 -reconfigure隐含-rebuild，但这些目标仅作用于软件包，并且不会触发重新生成根文件系统镜像。如果有必要重新生成根文件系统，则需另外运行make或make all命令。

在内部，Buildroot会创建所谓的stamp文件以跟踪每个软件包已完成的构建步骤，它们存储在output/build/-目录，并命名为.stamp_。上面详细介绍的命令仅操作这些标记文件即可强制Buildroot重新启动软件包构建过程的一组特定步骤。

有关软件包特殊构建目标的更多详细信息，请参阅第8.13.5节“特定软件包的构建目标”。

8.4 离线构建

如果你打算离线构建，并且只是想下载先前在配置器中（menuconfig、nconfig、xconfig或gconfig等）选择的所有软件包源码，运行以下命令：

make source

之后，你就可以断开网络连接或者拷贝dl目录到其他机器上构建。

8.5 目录树外构建

默认情况下，Buildroot生成的所有内容都存储在Buildroot目录树的output目录中。
Buildroot还支持使用类似于Linux内核的语法在目录树外构建。要使用它，在make命令中增加O=参数：

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 <target>

8.7 有效处理文件系统镜像

文件系统镜像可能会变得非常大，具体取决于你选择的文件系统、软件包的数量、是否配置了可用空间等。但是，文件系统镜像中的某些位置可能是空的（例如大段内容都为0），这样的文件称为稀疏文件。

很多工具可以有效地处理稀疏文件，并且只会存储或写入稀疏文件中不为空的部分。例如：

• tar 接受-S参数指定仅存储稀疏文件的非零块：
  • tar cf archive.tar -S [files…] 将有效地将稀疏文件存储在tar包中
  • tar xf archive.tar -S 将有效地从tar中提取稀疏文件
• cp 接受–sparse=WHEN选项（WHEN取值为auto、never或always）：
  • cp --sparse=always source.file dest.file 如果source.file大段为0，dest.file将生成稀疏文件

其他工具可能也有类似的选项，具体请查阅各自的使用手册。

如果你需要存储文件系统镜像（例如从一台计算机传输到另一台计算机），或者需要发送它们（例如发送给QA团队），那么可以使用稀疏文件。

但是请注意，如果通过dd将稀疏模式保存的文件系统镜像刷到设备可能会导致文件系统损坏（例如，ext2文件系统的块可能会损坏，当你读取这些块时，这些块可能不全为0）。你应该仅在构建机（即宿主机）上使用稀疏文件，而不是将稀疏文件传到目标设备上使用。

8.8 软件包之间的依赖关系图

Buildroot的工作之一是了解软件包之间的依赖关系，并确保它们以正确的顺序构建。这些依赖有时可能非常复杂，对于一个给定的系统，通常很难理解为什么Buildroot会将某个软件包引入构建。

为了帮助理解依赖关系，从而更好的理解嵌入式Linux系统中不同组件的作用，Buildroot能够生成软件包之间的依赖关系图。
要生成已编译的整个系统的依赖关系图，只需运行：

make graph-depends

你将在output/graphs/graph-depends.pdf找到依赖图。

如果你的系统很大，依赖关系图可能会太负责且难以阅读。因此，可以针对给定的软件包生成依赖关系图：

make <package>-graph-depends

生成的依赖关系图位于output/graph/-graph-depends.pdf。

请注意，依赖关系图是使用Graphviz项目中的dot工具生成的，该工具必须已安装在宿主系统上才能使用该功能。在大多数发行版中，它都以graphviz软件包的形式提供。

默认情况下，依赖关系图以PDF格式存储。但是，通过设置BR2_GRAPH_OUT环境变量可以切换到其他输出格式，譬如PNG、PostScript或SVG，支持dot工具-T参数支持的所有选项。

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可以是实际的软件包名称、全局名称、虚拟软件包的关键字（以虚拟软件包结束）、宿主软件包关键字。该软件包仍然会在关系图上，但没有其他依赖关系。
• –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 --no-transitive --colors=red,green,blue' make graph-depends

8.9 构建时间图表

当系统构建耗时很长时，了解哪些软件包耗时最长，看看是否可以采取措施来加快构建速度，有时会很有用。为了协助进行构建时间分析，Buildroot收集了每个软件包每个构建步骤的耗时时间，并支持基于该数据生成图表。

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

make graph-build

这将在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）。如果使用的Python版本低于2.7，还需要argparse模块（大多数发行版上为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 每个软件包对整个根文件系统大小的贡献的饼图。
• package-size-stats.csv CSV文件，给出每个软件包对根文件系统大小的贡献。
• file-size-stats.csv CSV文件，给出每个已安装文件对其所属软件包的大小贡献及对整个根文件大小的贡献。

graph-size依赖Python Matplotlib库（大多数发行版上为python-matplotlib）。如果Python版本低于2.7，还需要安装argparse库（大多数发行版上为python-argparse）。

与构建时间图表一样，BR2_GRAPH_OUT环境变量可以用来调整输出文件的格式。有关此环境变量的详细信息，请参阅第8.8节“软件包之间的依赖关系图”。

此外，可以通过BR2_GRAPH_SIZE_OPTS环境变量进一步调整生成的图表。可接受的选项有：

• –size-limit X, -l X 会将大小贡献值低于X%的软件包归入“其他”条目。默认情况下，X=0.01，意味着每个大小贡献低于1%的软件包将被归入“其他”。可接受的值得范围为[0.0, 1.0]。
• –iec, --binary, --si, --decimal 使用IEC（二进制，1024的乘方）或SI（十进制，1000的乘方，默认值）前缀。
• –biggest-first 按降序而不是升序对软件包排序。

注意，仅在完全重新构建之后收集的文件系统大小数据才有意义。在make graph-size之前一定要运行make clean all。

要比较两次Buildroot构建的根文件系统的大小，例如在修改配置或切换到另一个Buildroot版本时，请使用size-stats-compare脚本，它接受两个file-size-stats.csv文件（make graph-size命令生成）作为输入。有关该脚本的帮助文档，请参阅：

utils/size-stats-compare -h

8.11 顶层并行构建

注意：本节介绍了一个非常有用的实验性功能，该功能在某些非常规情况下会失败，使用风险请自负。

Buildroot能够对每个软件包执行并行构建：每个软件包都是由Buildroot使用make -jN（或与Make等效的构建方式）构建的。默认情况下，并行级别是CPU数量+1，但可以使用BR2_JLEVEL配置选项调整。

一直到2020.02版本，Buildroot都是以串行方式构建软件包：软件包一个接一个的构建，在软件包与软件包之间没有并行构建。从2020.02版本开始，Buildroot对顶层并行构建提供了实验性支持，通过并行构建不具有依赖关系的软件包，可以节省大量的构建时间。但是，此功能被标记为实验性功能，已知在某些情况下不起作用。

为了实验顶层并行构建，必须执行以下操作：

• 在Buildroot中启用BR2_PER_PACKAGE_DIRECTORIES选项。
• 使用make -jN启动构建

在内部，BR2_PER_PACKAGE_DIRECTORIES会启用称之为per-package directory的机制，这将产生以下效果：

• 区别于正常构建的全局target目录和全局host目录，顶层并行构建将分别为每个软件包生成target和host目录，即$(O)/per-package/<pkg>/target/和$(O)/per-package//host/。在软件包构建开始时，这些文件夹将使用依赖的软件包的文件夹填充。因此，编译器和其他工具将只能查看和访问该软件包依赖的软件包安装的文件。
• 构建结束后，全局target和host目录将被填充，分别位于$(O)/target和$(O)/host目录。这意味着在构建过程中，这些文件夹将为空，并且直到构建的最后才填充他们。

8.12 与Eclipse集成

一部分嵌入式Linux开发人员喜欢使用Vim或Emacs等传统文本编辑器和基于命令行的交互方式，而另一部分嵌入式Linux开发人员更喜欢有丰富图形界面的IED帮助他们完成开发工作。Eclipse是最流行的集成开发环境之一，Buildroot可以和Eclipse集成到一起以简化Eclipse用户的开发工作。

Buildroot与Eclipse的集成简化了在Buildroot系统上应用程序和库的编译、远程执行和远程调试。它不集成Buildroot配置，也不使用Eclipse构建自身。因此，使用Ecl集成环境的典型流程是：

• 使用make menuconfig、make xconfig或其他配置界面配置Buildroot系统。
• 运行make编译Buildroot系统。
• 启动Eclipse，开发、运行和调试你自己的应用程序和库，它们依赖于Buildroot构建和安装的库。

Eclipse集成Buildroot安装过程和用法可以参阅https://github.com/mbats/eclipse-buildroot-bundle/wiki。

8.13 高级用法

8.13.1 在Buildroot外部使用生成的工具链

你可能希望为目标系统编译未打包在Buildroot中的自己开发的应用程序或其他应用程序，为此你可以使用Buildroot生成的工具链。

Buildroot生成的工具链默认存储在output/host/目录。最简单的使用方式是将output/host/bin加入PATH环境变量，之后就可以使用ARCH-linux-gcc、ARCH-linux-objdump、ARCH-linux-ld等命令。

Buildroot也可以将工具链和所有选中的软件包导出为SDK，只需运行make sdk命令即可。这将把output/host打成一个tar包，并命名为_sdk-buildroot.tar.gz（可以通过BR2_SDK_PREFIX环境变量修改前缀），存储在output/images目录。
然后，将该tar包分发给其他开发人员，就可以开发尚未打包到Buildroot的软件包。

提取该SDK tar包后，用户必须运行relocate-sdk.sh脚本（位于SDK的顶层目录），以确保所有路径都更新为新路径。

此外，如果你只是想准备SDK但并不想打包（例如，你想移动host目录，或者想手动生成tar包），可以使用make prepare-sdk命令只准备SDK但不实际生成tar包。

8.13.2 在Buildroot中使用gdb

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：

<buildroot>/output/host/bin/<tuple>-gdb -x <buildroot>/output/staging/usr/share/buildroot/gdbinit foo

当然，foo必须在当前目录中可用，并且带有调试符号。通常，你应该从foo的构建目录调用以上命名（而不是从剥离了二进制调试符号的output/target目录）。

/output/staging/usr/share/buildroot/gdbinit将告诉交叉gdb在哪里可以找到目标依赖的库。

最后，使用交叉gdb连接目标：

(gdb) target remote <target ip address>:2345

8.13.3 在Buildroot中使用ccache缓存

ccache是编译器缓存。它存储每个编译过程中产生的目标文件，并能够跳过同一源文件的编译（使用相同的编译器和参数）。当从头开始进行几乎完全相同的构建时，它可以很好地加快构建过程。

Buildroot集成了ccache支持，你只需要在Build options选项中启用Enable compiler cache即可。这将自动构建ccache，并将其应用于所有宿主和目标编译。

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

make ccache-stats命令可以用来获取有关缓存的统计信息，包括大小、命中次数、未命中次数等。

构建目标ccache-options和CCACHE_OPTIONS变量提供了对ccache更通用的访问控制。例如：

# set cache limit size
make CCACHE_OPTIONS="--max-size=5G" ccache-options

# zero statistics counters
make CCACHE_OPTIONS="--zero-stats" ccache-options

ccache对源文件和编译选项计算HASH，如果编译选项不同，则不会使用缓存的目标文件。然而，许多编译器选项都包含staging目录的绝对路径，因此，编译到不同输出目录的构建将导致许多缓存未命中。

为避免此问题，Buildroot提供了Use relative paths选项（BR2_CCACHE_USE_BASEDIR），这将把指向内部输出目录的绝对路径重写为相对路径。因此，更改输出目录不会导致缓存未命中。

使用相对路径的一个缺点是最终生成的目标文件中会是相对路径。因此，除非你先cd到输出目录，否则调试器找不到该文件。
有关此绝对路径重写的更新详细信息，请参阅ccache用户手册“在不同目录中编译”部分。

8.13.4 软件包下载位置

Buildroot下载的各种压缩文件都存储在BR2_DL_DIR目录，默认情况下是dl目录。如果要保留一个完成的Buildroot版本以便与相关的压缩包一起使用，你可以复制该文件夹。这将允许你使用相同的版本重新生成工具链和目标文件系统。

如果你需要维护多个Buildroot树，那最好是使用共享的下载路径，可以通过将BR2_DL_DIR环境变量指向该目录实现。如果设置了该值，Buildroot配置中的BR2_DL_DIR将会被覆盖。以下内容需要添加到<~/.bashrc>。

export BR2_DL_DIR=<shared download location>

下载路径也可以通过.config文件的BR2_DL_DIR选项指定。与.config文件中的大多数选项不同，该值会被BR2_DL_DIR环境变量覆盖。

8.13.5 软件包make目标

运行make 将构建并安装该软件包及其依赖项。

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

make <package>-<target>

软件包构建目标有（按执行顺序排列）：

命令/目标	描述
source	获取源代码（下载压缩包，克隆源代码仓库等）
depends	构建并安装构建该软件包所需的所有依赖项
extract	将源代码放到软件包的构建目录中（提取压缩包，复制源代码等）
patch	应用补丁（如果有）
configure	运行configure命令，如果有
build	运行编译命令
install-staging	目标软件包：如有必要，在staging目录中安装软件包
install-target	目标软件包：如有必要，在target目录中安装软件包
install	目标软件包：运行以上两条安装命令宿主软件包：在host目录中安装软件包

此外，还有一些有用的make目标：

命令/目标	描述
show-depends	显示构建软件包所需的第一级依赖项
show-recursive-depends	递归显示构建软件包所需的依赖项
show-rdepends	显示软件包的第一级反向依赖项（即直接依赖于它的包）
show-recursive-rdepends	递归显示软件包的反向依赖项（即直接或间接依赖于它的包）
graph-depends	在当前Buildroot配置上下文中，生成软件包的依赖关系图。有关依赖关系图的更多详细信息，请参阅本节。
graph-rdepends	生成软件包的反向依赖关系图（即直接或间接依赖于它的软件包）
dirclean	删除整个软件包的构建目录
reinstall	重新运行安装命令
rebuild	重新运行编译命令，仅在使用OVERRIDE_SRCDIR功能或直接在构建目录中修改文件时才有意义
reconfigure	重新运行configure命令，仅在使用OVERRIDE_SRCDIR功能或直接在构建目录中修改文件时才有意义

8.13.6 在开发过程中使用Buildroot

Buildroot的一般操作是下载tar包、提取、配置、编译和安装该tar包内的软件。源代码提取保存在临时目录output/build/-目录中，当执行make clean时，该目录会被完全删除，并在下一次make时重新创建。即使将Git或Subversion等版本管理系统作为软件包源代码的输入，Buildroot也会从中创建一个tar包，然后像对待一般tar包一样工作。

这种方式非常适合将Buildroot当做集成工具，编译和集成嵌入式Linux系统的所有组件。但是，如果是在开发系统的某些组件的过程中使用Buildroot，这种方式非常不方便：开发者希望对一个软件包的源代码做少许修改，并能够使用Buildroot快速重建系统。
直接修改output/build/-不是合适的解决方案，因为该目录会在make clean时删除。

因此，Buildroot针对该场景提供了一种特殊的机制，即_OVERRIDE_SRCDIR机制。Buildroot读取一个override文件，该文件允许用户告诉Buildroot某些软件包的源代码位置。

默认的override文件是$(CONFI{G}_{D}IR)/local.mk，由BR{2}_{P}ACKAG{E}_{O}VERRID{E}_{F}ILE配置选项定义。$(CONFIG_DIR)是Buildroot .config配置文件所在的目录，因此local.mk默认情况下与.config文件放在一起，这意味着：

• Buildroot目录树内构建时位于Buildroot顶层目录中（当O=不使用时）
• Buildroot目录树外构建时位于目录树外目录（当O=使用时）

如果需要的位置与默认值不同，可以通过BR2_PACKAGE_OVERRIDE_FILE 配置选项指定它。

在override文件里，Buildroot希望找到以下形式的行：

<pkg1>_OVERRIDE_SRCDIR = /path/to/pkg1/sources
<pkg2>_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（只有修改过的文件会被复制），并重新启动这个软件包的构建过程。

在上述Linux软件包的示例中，开发人员可以修改/home/bob/linux目录下的源代码，然后运行：

make linux-rebuild all

这将在几秒钟内在output/images目录获得更新后的Linux内核镜像。同样，可以修改/home/bob/busybox目录下的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

默认情况下，Buildroot会跳过VCS信息（例如.git或.svn）的同步。一些软件包在编译过程中会使用VCS信息，例如精确确认提交信息。要取消Buildroot的内置过滤规则，需要重新添加以下目录：

LINUX_OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS = --include .git