CMake 递归查找Config.cmake设置_ROOT或CMAKE_PREFIX_PATH的方法咨询

针对插件化、无静态依赖、不想全量加载模块到IDE的项目场景，完全不需要依赖file(GLOB_RECURSE)就可以实现可靠的模块配置文件定位，以下是生产环境常用的、可封装成辅助宏的实现方法：

可替代GLOB_RECURSE的路径定位手段 #

1. 利用find_path的原生递归搜索能力 #

这个方法是CMake内置find_package逻辑的底层实现能力，比手写GLOB的可靠性更高，自带缓存机制不会重复扫盘：

• 封装成宏的核心逻辑：针对项目中模块的通用目录结构，通过find_path的通配符路径后缀能力，递归匹配目标*Config.cmake文件的所在层级，不需要自己写目录递归遍历逻辑
• 核心代码参考：

# 宏输入：搜索根目录、要定位的Config文件名、结果输出变量
macro(locate_config_root _root_dir _config_name _out_var)
  find_path(${_out_var}
    NAMES "${_config_name}"
    HINTS "${_root_dir}"
    PATH_SUFFIXES "*/lib/cmake" "*/cmake" "*/share/cmake"
    NO_DEFAULT_PATH
    DOC "Auto located root path for ${_config_name}"
  )
endmacro()

• 优势：搜索结果会被CMake缓存，重复执行配置时不会重复扫描磁盘；自带规则匹配能力，会自动跳过无关的隐藏目录、build目录，比手写GLOB的自定义过滤规则更靠谱。

2. 轻量模块索引预加载，完全规避递归扫盘 #

这是百模块规模以上大项目最常用的方案，速度比全量递归扫描高几个量级：

• 实现方式：在项目根目录维护一个薄的文本索引文件，只记录每个模块的相对路径，不需要遍历磁盘上的所有目录。
• 索引文件示例（存放在cmake/ModuleIndex.cmake）：

set(PROJECT_MODULE_INDEX
  "modules/core/LogLib"
  "modules/net/NetClient"
  "modules/render/GPUBackend"
  # 新增模块时只需要在这里追加一行路径即可
)

• 辅助宏逻辑：遍历索引列表，把每个模块的相对路径转成绝对路径，直接加入全局CMAKE_PREFIX_PATH，全程不需要递归扫描磁盘文件，配置阶段耗时基本可以忽略。

3. 直接复用find_package的原生搜索逻辑，不做提前扫描 #

这是资源占用最低的方案，完全不需要手动定位所有Config文件的位置：

• 实现方式：只需要把所有模块的上级根目录（比如${PROJECT_SOURCE_DIR}/modules）一次性加入CMAKE_PREFIX_PATH，同时配置好CMake查找配置文件的通用路径后缀规则。
• 核心配置代码：

# 一次性加入模块根路径
list(APPEND CMAKE_PREFIX_PATH "${PROJECT_SOURCE_DIR}/modules")
# 限制查找范围，避免扫描系统目录
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

• 效果：当你在某个可执行文件的CMakeLists里调用find_package(modX)时，CMake会自动在根路径下按照规则递归匹配对应的modXConfig.cmake，只有实际用到的模块才会触发查找，不会在配置阶段无意义扫描所有模块；同时因为只有被实际find_package调用的模块才会被加载到构建链路里，Visual Studio生成的解决方案里不会出现无关模块的工程节点，完全匹配轻量管理IDE工程的需求。

两种落地思路的优化建议 #

• 选择把Config.cmake所在路径加入CMAKE_PREFIX_PATH时，要避免一次性把所有模块路径全量加入：全量加路径会导致后续find_package的搜索路径膨胀，反而拖慢查找速度；正确的做法是按需触发，只有当前可执行文件实际依赖的模块被定位到之后，再把对应路径补充到全局搜索路径里。
• 选择生成模块对应<mod>_ROOT变量时，这个思路和CMake原生的包查找逻辑完全兼容：只需要把定位到的模块根路径存成缓存变量即可，后续find_package会自动优先匹配这些自定义的_ROOT变量，不需要额外写适配逻辑。

为什么不推荐使用file(GLOB_RECURSE) #

哪怕是作为临时实现手段，在大项目里使用GLOB_RECURSE扫描Config文件的问题非常突出：

• 全量扫描的耗时会随模块数量线性上涨，哪怕当前只需要构建单个可执行文件，也会遍历所有模块目录
• GLOB的扫描结果不会自动感知目录结构变化，新增模块后必须手动重新触发CMake配置才能识别
• 返回的全量文件列表会占用不必要的内存，在模块数量超过50个时，配置阶段的卡顿感会非常明显

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