这是CMake FetchContent使用中非常常见的需求——既不想重复存储依赖源码，又要保证Debug/Release等不同配置的二进制互不干扰。核心思路是把依赖的源码目录固定为共享路径，同时让依赖的构建目录随主项目的构建配置/构建目录隔离，完全不需要用不推荐的FetchContent_Populate，用官方支持的变量配置就能实现。

1. 固定共享的源码存储位置 #

首先，在你的<source_root>/lib/CMakeLists.txt里，先指定FetchContent的基础目录，同时为每个依赖单独强制设置源码路径，确保所有构建配置都共用同一份源码：

# 统一设置FetchContent的基础目录，放在lib下的fetchcontent文件夹
set(FETCHCONTENT_BASE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/fetchcontent")

# 为每个依赖指定固定的源码目录，避免不同构建目录重复拉取
# 比如依赖名为mylib：
set(FETCHCONTENT_SOURCE_DIR_MYLIB "${FETCHCONTENT_BASE_DIR}/mylib-src")

这样不管你是用Debug还是Release构建，mylib的源码只会被拉取到<source_root>/lib/fetchcontent/mylib-src这一个位置，不会重复存储。

2. 让依赖的构建目录随主项目配置隔离 #

这一步是解决“二进制混用”问题的关键——我们需要让每个构建配置（或每个主项目构建目录）拥有独立的依赖构建目录，这样不同配置的编译产物不会互相覆盖。

针对单配置生成器（Makefile、Ninja等） #

单配置生成器需要为不同配置创建独立的主项目构建目录（比如build-debug、build-release），此时我们需要为依赖指定构建目录为当前主项目构建目录下的_deps子目录：

# 让mylib的构建目录放在主项目构建目录的_deps下，随主项目配置隔离
set(FETCHCONTENT_BUILD_DIR_MYLIB "${CMAKE_BINARY_DIR}/_deps/mylib-build")

针对多配置生成器（Visual Studio、Xcode等） #

这类生成器支持在同一个构建目录下生成多配置产物，CMake会自动为每个配置创建子目录。同样设置构建目录为主项目的二进制目录下的_deps即可，CMake会自动处理不同配置的隔离：

# 同样的配置，Multi-Config生成器会自动在这个目录下创建Debug/Release等子目录
set(FETCHCONTENT_BUILD_DIR_MYLIB "${CMAKE_BINARY_DIR}/_deps/mylib-build")

3. 完整的依赖声明示例 #

把上面的配置整合到你的<source_root>/lib/CMakeLists.txt里，完整代码如下：

# 设置FetchContent基础目录，存放共享源码
set(FETCHCONTENT_BASE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/fetchcontent")

# 声明第一个依赖：mylib
set(FETCHCONTENT_SOURCE_DIR_MYLIB "${FETCHCONTENT_BASE_DIR}/mylib-src")
set(FETCHCONTENT_BUILD_DIR_MYLIB "${CMAKE_BINARY_DIR}/_deps/mylib-build")

FetchContent_Declare(
  mylib
  GIT_REPOSITORY https://github.com/example/mylib.git
  GIT_TAG v1.0.0
)

# 声明第二个依赖：anotherlib（同理配置）
set(FETCHCONTENT_SOURCE_DIR_ANOTHERLIB "${FETCHCONTENT_BASE_DIR}/anotherlib-src")
set(FETCHCONTENT_BUILD_DIR_ANOTHERLIB "${CMAKE_BINARY_DIR}/_deps/anotherlib-build")

FetchContent_Declare(
  anotherlib
  GIT_REPOSITORY https://github.com/example/anotherlib.git
  GIT_TAG v2.3.0
)

# 确保所有依赖可用
FetchContent_MakeAvailable(mylib anotherlib)

4. 验证与注意事项 #

• 单配置生成器验证：分别创建build-debug和build-release目录，进入build-debug执行cmake -DCMAKE_BUILD_TYPE=Debug ../并构建，再进入build-release执行cmake -DCMAKE_BUILD_TYPE=Release ../并构建。你会发现<source_root>/lib/fetchcontent下只有一份源码，而每个build-*目录下的_deps里有对应配置的二进制产物。
• 多配置生成器验证：直接用Visual Studio打开主项目的构建目录，切换Debug/Release配置并构建，依赖会自动编译对应配置的二进制，源码始终共用。
• 依赖兼容性：确保你拉取的依赖本身支持根据CMAKE_BUILD_TYPE或CMAKE_CONFIGURATION_TYPES生成对应配置的产物——绝大多数正规的CMake库都会处理这个逻辑。
• 避免FetchContent_Populate：正如你所说，CMake官方不推荐直接使用FetchContent_Populate，上面的方案完全基于官方推荐的FetchContent_Declare + FetchContent_MakeAvailable流程，更稳定且易维护。

内容的提问来源于stack exchange，提问作者RL-S