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 名称发生冲突（比如两个库都导出
jsontarget）
FetchContent_MakeAvailable 的典型写法与陷阱
常见错误是直接在 CMakeLists.txt 顶层调用，导致多次 fetch 或条件判断失效。正确做法是：先 declare，再按需 make_available，并加 if(NOT target_name_FOUND) 保护。
include(FetchContent)FetchContent_Declare( fmt GIT_REPOSITORY https://www.php.cn/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。你需要手动补上：
立即学习“C++免费学习笔记（深入）”；
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 都不一定有。
