CMake：如何处理同一子模块的多重依赖及版本冲突问题？

你的项目目录结构如下：

executable_A/
  CMakeLists.txt
  library_B/
    CMakeLists.txt
    library_C/
      CMakeLists.txt
  library_C/
    CMakeLists.txt

构建时会触发如下CMake错误：

add_library cannot create target "library_C" because another target with the
  same name already exists.  The existing target is an interface library
  created in source directory ".....".
  See documentation for policy CMP0002 for more details.

常见的规避方式是通过if(NOT TARGET library_C)判断后再添加子目录，但这种方案在executable_A和library_B依赖**不同版本library_C**时会失效，导致版本不匹配。针对你的问题，以下是可行的解决方案：

一、重命名子模块目标避免冲突 #

完全可以将library_B下构建的library_C目标重命名为library_C_B，有两种实现方式：

1. 直接修改子模块CMake配置 #

在library_B/library_C/CMakeLists.txt中，将目标名替换为library_C_B，并同步修改后续所有依赖该目标的配置：

add_library(library_C_B [STATIC/SHARED/INTERFACE]
  # 此处填写library_C的源文件列表
)

# 示例：同步修改头文件目录配置
target_include_directories(library_C_B
  PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include
)

这种方式简单直接，但如果library_C是Git子模块这类外部依赖，修改后需要维护自定义分支，灵活性有限。

2. 通过自定义参数传递实现动态命名 #

如果不想修改子模块的核心代码，可以给library_C的CMake配置增加一个可配置的目标名参数：

• 在library_B/CMakeLists.txt中，传递自定义目标名给子模块：

# 设置library_C的目标名为library_C_B，并传递给子模块
set(LIBRARY_C_TARGET_NAME "library_C_B" PARENT_SCOPE)
add_subdirectory(library_C)

• 在所有library_C的CMakeLists.txt中，使用这个参数作为目标名（默认值保留为library_C）：

# 优先使用外部传入的目标名，未传入则用默认值
set(LIBRARY_C_TARGET_NAME "library_C" CACHE STRING "Custom target name for library_C")
add_library(${LIBRARY_C_TARGET_NAME} [STATIC/SHARED/INTERFACE]
  # 源文件列表
)

这种方式无需修改子模块的核心逻辑，兼容性更好，适合管理Git子模块等外部依赖。

二、处理多版本library_C的依赖场景 #

如果确实需要让executable_A和library_B依赖不同版本的library_C，除了重命名目标外，还需要保证两个版本的库独立构建：

1. 指定独立的构建目录 #

在添加子目录时，通过第二个参数指定不同的构建目录，避免两个版本的编译产物冲突：

• 在executable_A/CMakeLists.txt中：

# 将顶层library_C的构建目录指定为library_C_build
add_subdirectory(library_C library_C_build)

• 在library_B/CMakeLists.txt中：

# 将library_B下的library_C构建目录指定为library_C_B_build
add_subdirectory(library_C library_C_B_build)

配合前面的目标重命名方案，就能同时构建两个版本的库，分别被对应组件链接。

2. 使用FetchContent管理多版本第三方依赖 #

如果library_C是外部第三方库，推荐使用CMake的FetchContent模块分别拉取不同版本，天然支持独立构建和目标隔离：

# 在executable_A中拉取v1版本的library_C
FetchContent_Declare(
  library_C_v1
  URL https://example.com/library_C_v1.tar.gz # 替换为实际的版本包地址或Git仓库
  GIT_TAG v1.0.0 # 如果是Git仓库，指定版本标签
)
FetchContent_MakeAvailable(library_C_v1)

# 在library_B中拉取v2版本的library_C
FetchContent_Declare(
  library_C_v2
  URL https://example.com/library_C_v2.tar.gz
  GIT_TAG v2.0.0
)
FetchContent_MakeAvailable(library_C_v2)

这种方式无需手动维护嵌套目录，能更清晰地管理多版本依赖。

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