Buildroot Config.in：select、depends on与工具链能力约束
菜单是有效性筛选，不只是开关列表
某个包在menuconfig中消失，可能是在提醒当前工具链或平台无法满足要求。直接删除依赖让选项出现，往往只是把问题推迟到编译、链接或运行阶段。真正需要确认的是：配置模型是否准确描述应用及其所选库的要求。本文固定使用Buildroot 2025.02，telemetry-view仅为虚构审查示例，没有作为软件包提交或执行构建。
先从上游构建说明提取必要条件，再对照所用版本的依赖库配方。应用升级、库升级和功能开关变化都可能改变条件；不能因为旧配置一直能构建，就认定依赖永远正确。
环境条件使用depends on
架构、MMU、线程、C库以及编译器能力属于包运行于其中的环境。软件包不能用select凭空创建这些条件。Buildroot通常对库使用select，对工具链和平台条件使用depends on，并为工具链缺项提供说明。具体惯例见2025.02配置参考。
真正需要C++和线程的应用应分别约束BR2_INSTALL_LIBSTDCPP和BR2_TOOLCHAIN_HAS_THREADS。其他条件必须有软件需求依据，不宜为保险全部加上。内核头文件版本描述的是工具链所用头文件，不能单凭这个符号证明目标机器正在运行的内核提供所有所需功能；运行时兼容性仍需单独核验。
select不会替你传播所有前提
假设库B依赖条件A，应用C选择B，这并不自动意味着C也依赖A。配置菜单能够选中C，但B的前提可能仍不成立。因此消费者必须显式传递相关约束，包括间接选中库的必要条件，而不能把select当成通用依赖求解器。
评审时沿着每条select关系逐层查看，直到架构和工具链条件得到解释，再将消费者条件与实际启用功能所需条件比较。也不要机械复制所有限制：可选功能可能只在启用时才需要更强条件。为传播的约束写明原因，后续升级才能判断哪些限制已经过时，而不是永久叠加。
说明文字也需要正确的可见条件
下面示例仅说明C++与线程条件，未选择具体库，因为实际库取决于应用。正式配方仍应补充帮助文字和上游地址。只要两个能力缺少任意一个，工具链说明就应该可见。
config BR2_PACKAGE_TELEMETRY_VIEW
bool "telemetry-view"
depends on BR2_INSTALL_LIBSTDCPP
depends on BR2_TOOLCHAIN_HAS_THREADS
comment "telemetry-view needs a toolchain w/ C++, threads"
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS如果还存在架构限制或父功能开关，说明项应重复相应的非工具链条件，或者让包和说明共同置于适当的if块中。否则在根本不支持的平台上，用户会收到“换工具链即可”的误导；反过来，缺少说明又会让本来可支持的选项看起来无故消失。
make构建顺序仍需单独声明
Kconfig中的select负责启用软件包，并不单独保证所需构建顺序。真正的库依赖还应写入消费者的DEPENDENCIES变量。生成源码所用的宿主工具也必须进入正确的host依赖关系，不能与目标运行库混为一谈。可对照2025.02通用基础设施查看依赖如何进入构建规则。
验证时使用新的输出目录，旧staging中的头文件会掩盖缺失顺序依赖。与此同时，即便make依赖完全正确，也无法修复不满足前提的工具链。应分别审查配置有效性与执行顺序，最后确认二者针对的是同一组启用功能。
先做真值表，再做完整构建
示例有两个布尔能力，可以列出四种组合。只有C++和线程同时存在时，应用选项才应可用；其余三种在平台与父条件允许时显示说明。再用不支持架构或关闭父功能复测一个代表性组合，此时既不应显示应用，也不应给出无效的工具链建议。
为每个依赖库的关键约束和可选子功能补充行，比只测试量产defconfig更能发现漏洞，因为量产配置可能恰好启用了全部能力。检查配置处理后的最终.config，不能把片段中写了某个符号当作最终仍启用的证据。每行保存预期值、实际值及Kconfig警告，形成可以复查的配置测试结果。
解释警告，不要削弱模型
select导致未满足依赖时，优先检查消费者遗漏条件或错误的选择路径。递归依赖需要查看完整环路，而不是随意删除一条边直到警告消失。菜单可见但功能探测失败，则可能是配方模型不准确，或者软件升级后新增了要求。
把缺失事实归入工具链、架构、可选功能、提供者或make构建图，再修正对应层。与修复一起保存最小复现配置。一次编译器命令成功不能外推为普遍能力结论；即便版本号相同，架构和ABI组合也可能决定是否具备某项能力。
验收与后续维护
验收条件包括：支持的配置可选，不支持的配置不可选；工具链缺项有恰当说明；select链上的前提已经传递；make依赖能保证正确顺序。项目应计划至少一次新输出目录构建和相关负向配置测试，本文没有执行这些产品验证。
把真值表与包评审记录一起保存，下次升级依赖时便能明确更新哪些要求。这只能证明选择模型可维护，并不能证明运行时行为、安全维护期限或与所有内核镜像兼容。后面的产品测试应以配置实际产生的软件为基础继续进行。
