Automake中check-am依赖all-am的设计原因是什么？

为什么默认会有这个依赖？ #

• 递归构建的局限性导致的兜底方案：在传统递归构建模式下，各子目录的Makefile相对独立，Automake无法精准预判哪些测试用例依赖哪些具体编译目标。如果不强制先完成全量构建，很可能出现测试执行的是旧版本二进制文件或库的情况，直接导致测试结果失效。依赖all-am（全量构建）是最稳妥的通用做法，确保所有可能被测试用到的资源都处于最新状态。
• 通用性优先的设计思路：Automake需要适配从简单单文件工具到复杂多组件系统的各类项目。默认全量依赖能避免用户因漏写依赖规则导致的测试失败，降低工具使用门槛，不用让每个用户都手动梳理测试与目标的依赖关系。

明确依赖场景下的优化方式 #

如果你的项目采用非递归构建，或者已经通过编译器生成的依赖信息（比如gcc -MM生成的头文件依赖）明确了测试与目标的关联，默认全量构建就会显得冗余。可以通过以下方式调整：

• 重定义check-am目标：在Makefile.am中手动指定测试实际依赖的目标，例如：

  check-am: my_test_executable core_library
  

• 利用TESTS自动依赖特性：如果测试用例是Automake管理的可执行文件，它会自动为每个测试文件添加对应的构建依赖，前提是你已在Makefile.am中正确声明了测试文件的编译规则和依赖。

内容的提问来源于stack exchange，提问作者Caulder