Buildroot构建指南--快速上手与实用技巧

谁借莪１个温暖的怀抱￠ 2022-05-14 05:08 161阅读 0赞

Buildroot官方全英文使用手册的链接是[https://buildroot.org/downloads/manual/manual.html][https_buildroot.org_downloads_manual_manual.html]，需要知道每一个细节的朋友，可以仔细查阅，这篇文章只是我自己从中提炼出来的一下快速上手的技巧。

# 如何在现有项目加入自己的APP #

Buildroot从零开始构建的过程还是很复杂的，以后的文章会一步步介绍。我们先来看看如何在现有项目中加入一个自己的应用的构建方法，快速上手。实际上，快速添加应用包的方法，在官方网站也有一份英文文档:[https://buildroot.org/downloads/manual/manual.html\#adding-packages][https_buildroot.org_downloads_manual_manual.html_adding-packages]  详细的原理可以参考这篇文档。

这里以加入自己的demo\_app应用为例，在mini2440\_defconfig的项目下，加入demo\_app的package，将demo\_app的应用源代码编译生成到rootfs根文件系统中。构建方法如下:

1.      在buildroot/package/ 下执行 mkdir demo\_app  ，创建demo\_app 的文件夹

![Center][]

Figure1 在package/ 目录下创建demo\_app/

2.      在demo\_app 中touch Config.in , touch demo\_app.mk 创建这两个文件，注意，文件名很关键，demo\_app.mk要小写，而且不能乱取其它名字，因为Buildroot框架有一套根据命名，展开app package的规则，所以buildroot里面构建项目，一定要遵守文章中的命名规则，否则会有各种报错。

![Center 1][]

Figure2  添加Config.in 与 demo\_app.mk 文件

3.      在package/Config.in 中加入 source "package/demo\_app/Config.in" ，以便将demo\_app 的配置文件包含到Buildroot的package中来管理。

![Center 2][]

Figure3  在packahe/Config.in 中加入demo\_app的Config.in

4.      在package/demo\_app/Config.in 这个类似Kconfig的配置文件中，按照命名格式和Linux Kernel 的 Kconfig文件规范，加入自己的配置变量，参考代码如下:

1.  `config BR2_PACKAGE_DEMO_APP`
2.  `bool"demo app"`
3.  `help`
4.  `demo app to show`

这段配置中，命名规则也同样重要，BR2\_PACKAGE\_DEMO\_APP是demo\_app 可被Buildroot识别编译成package的配置变量。Package应用一定要以BR2\_PACKAGE\_作为开头，以DEMO\_APP即demo\_app的大写来填充这个变量名，这样才能被Buildroot命名框架识别、展开，才能通过make menuconfig来配置。

bool是变量的类型，即只要true(编译选中，false(编译未选中)，两种情况，和Kconfig的规则是一样的，后面的字符串和help都是在make menuconfig时的提示文本。

实际上，在Config.in中，可以参考Linux Kernel的Kconfig文件，根据语法规范，加入自己的配置逻辑和其它可配置的变量(比如app的下载地址链接)，在此就不详细说了，大家可以参考其它的package/的Config.in文件的写法，这里只说重点，就是BR2\_PACKAGE\_DEMO\_APP这个变量一定要有，一定要被选上才能编译。

5.      在demo\_app.mk中，按照Makefile文件的格式和语法规范，编写demo\_app的上层构建规则，demo\_app.mk的参考代码如下:

1.  `################################################################################`
2.  `#`
3.  `# demo app`
4.  `#`
5.  `################################################################################`
6.  `DEMO_APP_VERSION = master`
7.  `DEMO_APP_SITE_METHOD = git`
8.  `DEMO_APP_SITE = /mnt/sdb/git_repo/demo_app`
9.  `DEMO_APP_SOURCE = demo_app-$(DEMO_APP_VERSION).tar.gz`
10. `DEMO_APP_ALWAYS_BUILD = YES`
11. `DEMO_APP_INSTALL_STAGING = YES`
12. `DEMO_APP_CFLAGS =`
13. `DEMO_APP_LDFLAGS =`
14. `OUT_BIN = demo_app`
15. `DEMO_APP_MAKE_FLAGS += \`
16. `CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \`
17. `CC=$(TARGET_CC) \`
18. `OUT_BIN=$(OUT_BIN) \`
19. `AR=$(TARGET_AR) \`
20. `STRIP=$(TARGET_STRIP) \`
21. `CFLAGS=$(DEMO_APP_CFLAGS) \`
22. `LDFLAGS=$(DEMO_APP_LDFLAGS) \`
23. `STAGING_DIR=$(STAGING_DIR) \`
24. `TARGET_DIR=$(TARGET_DIR)`
25.  
26. `define DEMO_APP_BUILD_CMDS`
27. `$(MAKE) clean -C $(@D)`
28. `$(MAKE) $(DEMO_APP_MAKE_FLAGS) -C $(@D)`
29. `endef`
30.  
31. `define DEMO_APP_INSTALL_TARGET_CMDS`
32. `$(INSTALL) -m 0755 -D $(@D)/$(OUT_BIN) $(TARGET_DIR)/usr/bin`
33. `endef`
34.  
35. `$(eval $(generic-package))`

注意，demo\_app.mk并不能实际代替demo\_app源代码的Makefile文件，它只是一个上层的make文件，告诉Buildroot，应该到哪个地方拿源代码，应该如何解压源代码，应该给源代码中的Makefile中的变量传递哪些编译参数，编译出来的库和bin文件，应该安装到rootfs的哪个路径下。具体demo\_app源代码是如何一步一步编译的，还得靠demo\_app源代码本身的Makefile去做。

这段makefile代码大概有什么规范呢：

a)     所有的变量都已DEMO\_APP\_ 开头，这样Buildroot才能够通过命名框架去解析

b)     \_VERSION结尾的变量，是下载demo\_app源代码的版本号， \_SITE\_METHOD结尾的变量是demo\_app变量的下载方法，\_SITE结尾的变量是demo\_app的下载地址，其它的变量是干嘛用的，可以慢慢查阅官方手册。

c)      所有define 并以\_CMDS结尾的代码块，类似函数的东西，实际上是构建过程中会被Buildroot框架执行的指令，这些指令到底有哪些，具体也得读手册。当然这些类似函数，开头也得是DEMO\_APP\_， Buildroot中命名规则很重要，重要的话说三遍。

d)     \_BUILD\_CMDS结尾的函数，是构建过程函数，一般是给demo\_app源代码传递编译和链接选项，调用源代码的Makefile执行编译。

e)     INSTALL\_TARGET\_CMDS结尾的函数，就是demo\_app编译完之后，自动安装的执行，一般是让Buildroot把编译出来库和bin文件安装到指定的目录。

f)      $(eval$(generic-package)) 最核心的就是这个东西了，一定不能够漏了，不然demo\_app是编译不出来的，这个函数就是把整个demo\_app.mk构建脚本，通过Buildroot框架的方式，展开到Buildroot/目录下的Makfile中，生成demo\_app的构建目标(构建目标是什么，还记得Makefile中的定义吗？)。

g)     实际上，这些构建命名框架还有$(eval $(generic-package))这个黑魔法，都在package/pkg-generic.mk 这个文件中，generic-package是这个文件最后的调用的函数生成的，其它 \_BUILD\_CMDS，INSTALL\_TARGET\_CMDS这些函数如何被Buildroot框架嵌入的, 之前那些变量是如何被调用的，在package/pkg-generic.mk中都能找到，但是还是要一定的Makefile功底才能读懂这个的，以后再解释package/pkg-generic.mk的框架原理。

讲了这么多条规范，那么这段makefile代码大概是什么意思呢？

这段代码描述的流程是， 通过git  clone的方法从/mnt/sdb/git\_repo/demo\_app这个目录下的git仓库中拿到demo\_app的源代码-->传递编译参数，并且编译demo\_app(DEMO\_APP\_BUILD\_CMDS函数做的事情)-->把编译出来的bin文件安装到$(TARGET\_DIR)/usr/bin目录下(DEMO\_APP\_INSTALL\_TARGET\_CMDS函数做的事情)。

为什么我们自己不用写从git仓库下载demo\_app源代码的函数呢，实际上是Buildroot帮我们写好了，在package/ pkg-download.mk 文件里面，所以我们只有通过DEMO\_APP\_SITE\_METHOD和DEMO\_APP\_SITE设置下载的方法和地址就可以。至于为什么DEMO\_APP\_VERSION是master，了解git的朋友应该看得明白，就是git clone之后会checkout到master版本，其实也就是master分支最新的版本啦，当然也可以换成自己的版本号，前提是该版本号存在，能够用git checkout 切换过去。

这段代码的执行前提是要在Linux上搭建自己的git仓库，维护自己的demo\_app源代码，在用Buildroot前，git仓库是现成的。

但是不熟悉git 的朋友怎么办呢？其实还有其它方法，demo\_app.mk的代码稍做修改：

![Center 3][]

Figure4  采用file方法下载源代码

主要，DEMO\_APP\_SITE\_METHOD改成了file，这样就不用构建git参考，可以用file，也就是直接cp的方法，把源代码拷贝到buildroot中来。但是buildroot到哪里去cp源代码呢，实际上，这里不是DEMO\_APP\_SITE = /mnt/sdb/git\_repo/demo\_app这个地址，这个地方被我注释掉了。

在buildroot/下 makemenuconfig --> Build options -->Mirrors and Download locations 可以看到以下的画面：

![Center 4][]

Figure5  设置file方法cp文件的路径

只有按照上面的格式，也就是file:// + 你的文件绝对路径的地址的格式配置这个选项，然后保存，就OK，之后Buildroot就知道去该路径下找源代码包了。

另外记得，一定要把demo\_app的源代码压缩包保存到该路径下，并且名字一定要和DEMO\_APP\_SOURCE变量的名字一样哦！

![Center 5][]

Figure6  demo\_app 源代码的存放路径

6.      demo\_app的源代码

demo\_app就是一个hello world 程序参考的makefile和源代码如下：

其中Makefie会被demo\_app.mk中的DEMO\_APP\_BUILD\_CMDS函数调用，Makefie中的变量参数的值都可以通过DEMO\_APP\_BUILD\_CMD传入。

![Center 6][]

Figure7 demo\_app 的Makefie

![Center 7][]

Figure8  demo\_app.c 源代码

7.      构建方法

a). make mini2440\_defconfig  --> makemenuconfig --> Target packages下选中demo app --> make demo\_app

![Center 8][]

Figure9  menuconfig中选中 demo app，

make demo\_app这个命令，实际上是只是编译demo\_app以及demo\_app依赖链上的package， 当然，toolchain会被所有package依赖，所以buildroot会先编译toolchain。

编译完成后，会发现buildroot/output/build/目标下的demo\_app-master目录，即demo\_app编译后现场，以及在buildroot/output/target/usr/bin/目录下，安装好的编译出来的demo\_appbin文件。并且确实是ARM交叉工具链编译出来的。

![Center 9][]

Figure10  demo\_app 源代码编译现场路径

![Center 10][]

Figure11  安装好的demo\_app  bin文件

至此，在Buildroot中添加app package的过程就完成了。

# 如何编译基于现有项目的最小系统 #

Buildroot 一次make all要把整个系统编译出来，真麻烦，我只想要一个可以boot起来的最小系统，不需要什么其它package，它有什么快捷方式可以办到吗？这个当然问buildroot，我们可以这么做。

make help 看看buildroot怎么说

![Center 11][]

Figure12 make help 之后的buildroot系统提示

以下是buildroot的help命令提示，其中有一项是

make  allnopackageconfig

在make xxx\_defconfig 之后，执行make allnopackageconfig，那么再make all就可以只编toolchain，boot，kernel，busybox，rootfs这个几个能构成系统启动的最小系统的模块。

当然，在make mini2440\_defconfig时，由于mini2440的toolchain是toolchain-buildroot，即buildroot从零开始制作工具链，而不是toolchain-external，即buildroot使用已经制作好的工具链，这样的话，如果toolchain还没有在前一次生成，则make allnopackageconfig 再make all之后编译过程会报错，因为制作零制作toolchain需要编译某些package作为原材料，而这些package被make allnopackageconfig去掉了。

已经制作好工具链，或者采用toolchain-external模式的情况下，make allnopackageconfig 编译最小系统是没用问题的。

# Buildroot实用技巧与指令 #

最后看看buildroot有哪些实用技巧：

make help

\-之前演示过了，打印出帮助菜单

make show-targets

\-         显示出本次配置所要编译所有的目标，这些目标可以单独作为模块，用 make <pkg-target> 命令进行单独编译。从这条命令的显示结果来看，mini2440\_defconfig需要编译uclibc(微型C库)，busybox等目标，当然demo\_app也是一个编译目标，是我在menocunfig时候加进去的，所以可以用make demo\_app来编译。

![Center 12][]

Figure13  make show-targets 的显示结果

make <pkg-target>

\-         单独编译某个pkg模块以及其依赖的模块，比如make demo\_app

make pkg-rebuild

\-         重新编译pkg

make  pkg-extract

\-         只下载解压pkg,不编译，pkg解压后放在 output/build/目录对应的pkg-dir目录下

make pkg-source

\-         只下载某pkg，然后不做任何事情

其它还有很多快捷指令，在package/pkg-generic.mk中都能找到，这些快捷指令实际是是由pkg-指令这种命名框架合成的，更详细的内容请参考手册和package/pkg-generic.mk。

![Center 13][]

Figure14  package/pkg-generic.mk 框架下所支持的指令部分截图呀

[https_buildroot.org_downloads_manual_manual.html]: https://buildroot.org/downloads/manual/manual.html
[https_buildroot.org_downloads_manual_manual.html_adding-packages]: https://buildroot.org/downloads/manual/manual.html#adding-packages
[Center]: /images/20220514/42a83e4eb243460aab1c5a0adbe76384.png
[Center 1]: /images/20220514/296478420b774ebfbbc4c956b042ec61.png
[Center 2]: /images/20220514/c994026c3d59461ca8e63a454604bc0f.png
[Center 3]: /images/20220514/dbaaa77b61d8424b917a5be107efe659.png
[Center 4]: /images/20220514/5778ac905e4b43058fe2a43fd0306233.png
[Center 5]: /images/20220514/5e47e2ed55e848aaac0e35157e2aa8c7.png
[Center 6]: /images/20220514/0594c29531934a639ce00d4d433e950e.png
[Center 7]: /images/20220514/c1afb6031c064660ab3ba0e6b40b3353.png
[Center 8]: /images/20220514/c61a0805e0d64ca3803245886a673568.png
[Center 9]: /images/20220514/d403ff9e5a3d41e292c1f5c06e0b3b06.png
[Center 10]: /images/20220514/5fe72c8c8d2c477080d91cf402015bd4.png
[Center 11]: /images/20220514/d216c69334b64c589d44fbeae4401b1d.png
[Center 12]: /images/20220514/2a4d1a8581954df59f70477412f3974f.png
[Center 13]: /images/20220514/852adc2a6772459bac2c3407d85da4fc.png