CMake中FetchContent为何优先选择子目录合并而非安装依赖？

问题1：为什么默认采用add_subdirectory()满足依赖，而非先构建安装依赖再执行等效find_package()的逻辑？为何前者更适合作为默认行为？ #

• 配置一致性：add_subdirectory会将依赖直接纳入主项目的构建树，依赖会复用主项目的所有编译配置（编译器版本、编译选项、目标架构、运行时库选择等），从根本上避免了依赖与主项目ABI不兼容、配置不匹配的问题。如果采用先独立构建安装再find_package的方案，需要开发者手动对齐依赖与主项目的所有编译参数，跨平台场景下维护成本极高。
• 构建效率更高：纳入同一构建树后，依赖可以和主项目的目标并行构建，且完全复用CMake的增量构建逻辑。独立构建安装的方案需要额外执行依赖的配置、构建、安装全流程，还需要处理跨平台的安装路径权限、路径规则问题，整体耗时更长。
• 易用性更强：默认行为对下游开发者非常友好，不需要手动管理依赖的安装路径、搜索路径，拉取源码后直接可以使用依赖提供的导入目标，没有额外的学习和配置成本。

当然CMake也支持「优先找已安装的依赖，找不到再拉源码构建」的逻辑，只需在FetchContent_Declare中添加FIND_PACKAGE_ARGS参数即可切换行为，默认选择add_subdirectory是面向通用场景的折中选择。

问题2：是否需要将项目根目录的CMakeLists.txt编写为兼容被add_subdirectory()引入的形式？ #

这取决于你的项目定位：

• 如果是面向公众的开源库，强烈建议兼容add_subdirectory引入的场景。现在大量下游项目会通过FetchContent直接拉取源码构建，兼容该模式可以大幅降低下游的使用门槛。而且你提到的约束其实本身就是现代CMake的最佳实践：
  • 所有项目级选项添加项目前缀本身就应该做，不管是不是作为子项目，都能避免和其他项目的选项冲突
  • 依赖查找的逻辑遵循现代CMake规则，不要强制重写已经找到的依赖目标，即可避免和父项目的依赖查找逻辑冲突
    可以借助CMake 3.21新增的PROJECT_IS_TOP_LEVEL变量优化逻辑：只有当项目作为顶级项目构建时，才开启测试、示例、安装规则等子项目不需要的功能，进一步减少作为子项目时的构建冗余。
• 如果是仅内部使用的私有项目，且团队内部已经统一了find_package的依赖管理流程，不需要兼容的话可以不做额外处理。

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