FetchContent适用于轻量、纯CMake构建的头文件库或源码库，需手动管理路径与find_package；不支持多版本隔离、交叉编译配置及构建缓存，大型项目易失控。

用 FetchContent 管理现代 C++ 项目依赖，是可行的，但只适合轻量、可控、无构建系统冲突的第三方库——它不是万能替代品，更不是 vcpkg 或 conan 的平替。

什么时候该用 FetchContent_Declare？

适用于：头文件库（如 fmt、spdlog、range-v3）、纯 CMake 构建的源码库（如 catch2），且你愿意承担其构建过程完全嵌入主项目的代价。

• 你不需要独立安装步骤，希望“克隆即用”
• 你明确知道该库不依赖外部构建工具（比如没用 autotools 或 meson）
• 你接受它的编译选项（CMAKE_BUILD_TYPE、MSVC_RUNTIME_LIBRARY 等）会继承自主项目
• 你不怕它和主项目链接顺序、target 名称发生冲突（比如两个库都导出 json target）

FetchContent_MakeAvailable 的典型写法与陷阱

常见错误是直接在 CMakeLists.txt 顶层调用，导致多次 fetch 或条件判断失效。正确做法是：先 declare，再按需 make_available，并加 if(NOT target_name_FOUND) 保护。

include(FetchContent)
FetchContent_Declare(
fmt
GIT_REPOSITORY https://www./link/aa4e319d28b0e5f982bcc2fdc940deb8
GIT_TAG        10.2.1
SOURCE_DIR     "${CMAKE_BINARY_DIR}/_deps/fmt-src"
)
避免重复 fetch + 构建
if(NOT fmt_POPULATED)
FetchContent_Populate(fmt)
add_subdirectory("${fmt_SOURCE_DIR}" "${fmt_BINARY_DIR}")
endif()

• FETCHCONTENT_FULLY_DISCONNECTED 设为 ON 可禁用网络，但必须提前手动放好源码到 SOURCE_DIR
• 别用 FetchContent_MakeAvailable —— 它内部会无条件 Populate，无法控制时机
• SOURCE_DIR 必须显式指定，否则默认路径可能被清理或与其他库冲突

如何让 FetchContent 库支持 find_package？

很多库（如 fmt）自带 fmt-config.cmake，但 FetchContent 不会自动注册到 CMAKE_PREFIX_PATH。你需要手动补上：

if(NOT fmt_POPULATED)
  FetchContent_Populate(fmt)
  add_subdirectory("${fmt_SOURCE_DIR}" "${fmt_BINARY_DIR}")
  # 手动把 config 路径加入查找范围
  list(APPEND CMAKE_PREFIX_PATH "${fmt_BINARY_DIR}")
endif()
find_package(fmt REQUIRED)

• 如果库没有提供 config 文件（比如老版本 spdlog），就得用 add_subdirectory 后直接 target_link_libraries(myapp PRIVATE spdlog::spdlog)
• find_package 成功的前提是：目标已存在（add_subdirectory 已执行）且 config 路径可查（靠 CMAKE_PREFIX_PATH 或 PATHS 参数）

为什么大型项目不该只靠 FetchContent？

当依赖出现以下任一情况时，FetchContent 就开始失控：

• 多个子模块共用同一依赖但版本不同（FetchContent 不支持多版本隔离）
• 依赖本身需要交叉编译配置（比如 openssl 的 no-asm、enable-shared）
• 依赖构建耗时长（每次 clean 构建都会重 fetch + rebuild）
• 团队协作中有人想换源（比如国内镜像），而 FetchContent 没有统一 registry 机制

真正复杂点在于：它看起来简单，实则把依赖的构建生命周期和主项目强耦合了——一旦某个库改了 CMake 接口或 target 名称，你的整个构建就静默崩掉，连 warning 都不一定有。