📚 课程目录第4章 Buildroot 配置系统

4. Buildroot 配置系统

Buildroot 的配置系统源自 Linux 内核的 Kconfig 机制，它把成千上万个软件包、工具链选项、目标板参数组织成一棵可交互的配置树。理解 Kconfig 语法、Config.in 的组织方式、defconfig 的用法以及依赖与可见性控制，是软件包开发工程中最基础也最关键的一环。只有把配置系统用对，软件包才能被正确选中、正确编译，并在不同目标板之间稳定复用。

一、Kconfig 语法核心：配置项、类型与提示

Kconfig 文件由若干配置项（config entry）组成，每个配置项以 config 关键字开头，后跟符号名。符号名通常使用 BR2_ 前缀，例如 BR2_PACKAGE_MYPKG。配置项的类型决定了它在 .config 中的取值形式，常见类型有 bool、tristate、string、int、hex。Buildroot 中绝大多数软件包开关使用 bool，因为 Buildroot 默认把包静态编入根文件系统，而不是像内核那样支持模块。

config BR2_PACKAGE_MYPKG
    bool "mypkg"
    depends on BR2_USE_MMU
    select BR2_PACKAGE_LIBFOO
    help
      This is my package for Buildroot.
      It provides a demo service.

其中 bool "mypkg" 中的字符串是提示（prompt），只有带提示的配置项才会出现在 menuconfig 界面中。没有提示的配置项只能被其他项 select 或由 defconfig 直接赋值，用户无法手动切换。这一点在编写隐藏依赖项时非常有用。

二、Config.in 的组织方式：目录树与菜单

Buildroot 顶层 Config.in 通过 source 语句递归包含子目录中的 Config.in 文件，形成与源码目录对应的配置树。软件包通常放在 package/<name>/Config.in，并由 package/Config.in 按类别 source 进来。菜单结构由 menu、endmenu、comment 等关键字控制。

menu "My packages"

config BR2_PACKAGE_MYPKG
    bool "mypkg"
    help
      Demo package.

endmenu

组织 Config.in 时，应遵循“一个包一个 Config.in、按功能分类挂载”的原则。不要把多个包的配置项混写在一个文件里，否则后续维护、依赖追踪和 defconfig 复用都会变得困难。对于带子选项的包，可以用 if 块或 depends on 把子项限制在父项开启时才可见。

三、依赖与可见性控制：depends on、select 与 if

Kconfig 中控制配置项是否可见、是否可选，主要依靠 depends on 和 select。二者的语义完全不同：depends on 是“我依赖别人”，别人不满足时我不可见；select 是“我强制拉取别人”，我开启时别人被自动置为 y。滥用 select 会破坏依赖链，导致被选中的包缺少其自身依赖，从而出现编译失败。

常见误区：用 select 去“解决”依赖，而不是用 depends on 表达依赖。正确做法是：本包需要某库时，用 depends on BR2_PACKAGE_LIBFOO 表达前置条件；只有当本包确实要强制启用某个功能开关时，才使用 select。

可见性还受 if 块影响。if BR2_PACKAGE_MYPKG ... endif 内的配置项只有在父项开启时才参与配置。此外，comment 常用于在依赖不满足时给出提示，例如“需要 MMU 支持”，帮助用户理解为什么某个包不可见。

四、defconfig 使用：从配置到可复现构建

defconfig 是保存配置结果的精简文件，通常放在 configs/ 目录下，命名如 myboard_defconfig。它只记录与默认值不同的配置项，因此体积小、可读性好，非常适合版本管理。使用流程如下：

执行 make myboard_defconfig，Buildroot 读取 defconfig 并生成完整 .config。
执行 make menuconfig 交互调整配置。
执行 make savedefconfig，把当前配置回写为精简 defconfig。
提交 defconfig 到仓库，保证团队与 CI 使用同一份配置。

make myboard_defconfig
make menuconfig
make savedefconfig
cp defconfig configs/myboard_defconfig

建议：每次修改配置后都执行 make savedefconfig，避免把自动生成的冗余项提交进仓库。defconfig 中只保留真正有意义的开关，能让后续 diff 更清晰。

五、案例与复盘：新增软件包时的配置检查清单

假设我们要新增一个 mypkg 包，它依赖 BR2_USE_MMU，并需要 libfoo。正确的配置写法是：在 package/mypkg/Config.in 中声明 depends on BR2_USE_MMU 和 depends on BR2_PACKAGE_LIBFOO，而不是用 select 强行拉取。然后在 package/Config.in 的合适菜单中 source 该文件，最后在 defconfig 中开启 BR2_PACKAGE_MYPKG=y。

检查项	正确做法	常见错误
配置项命名	使用 `BR2_PACKAGE_<NAME>` 前缀	随意命名，导致冲突或不可读
依赖表达	用 `depends on` 表达前置条件	用 `select` 强行拉取依赖
可见性	用 `if` 或 `depends on` 控制子项	子项无条件可见，误选后编译失败
defconfig	用 `savedefconfig` 生成精简文件	直接提交完整 `.config`
帮助信息	为每个可见项写 `help`	无帮助文本，用户无法判断用途

复盘时最常见的问题是“配置能选但编译失败”，根源往往不是 Makefile，而是 Kconfig 依赖没有表达完整。另一个高频问题是 defconfig 与 .config 不一致，导致本地能编、CI 编不过。把 Kconfig 当作软件包的第一道接口来设计，依赖、可见性、默认值和帮助信息都写清楚，后续的包开发、板级适配和持续集成才会顺畅。