CMake多Git子模块依赖重复目标错误的解决方法

针对你遇到的多Git仓库CMake静态库嵌套依赖导致重复目标的问题，结合你的核心限制（b可独立构建、无需安装库），以下是几种可行的解决方案：

方案1：用if(NOT TARGET)包裹add_subdirectory（最小改动方案） #

这是解决此类重复定义问题的常用实用手段，完全适配你的现有结构：

• 在b的根目录CMakeLists.txt中：

  # 仅当目标a未定义时，引入子模块a
  if(NOT TARGET a)
      add_subdirectory(a)
  endif()
  

• 在c的根目录CMakeLists.txt中：

  # 先处理a的依赖
  if(NOT TARGET a)
      add_subdirectory(a)
  endif()
  # 再处理b的依赖
  if(NOT TARGET b)
      add_subdirectory(b)
  endif()
  

优势 #

• 无需修改现有Git子模块结构
• 完全满足b独立构建的需求：单独构建b时，a目标不存在，会自动引入内部的a子模块完成构建
• 构建c时，根目录的a先被引入，b内部的a子模块会被跳过，从根源避免重复目标错误
• 实现简单，无额外复杂度

方案2：使用CMake FetchContent替代Git子模块（现代化依赖管理） #

如果想摆脱子模块的嵌套冗余，可以用CMake 3.11+内置的FetchContent模块，它能自动从Git拉取依赖并处理重复引入：

1. 保持各库的独立构建能力（每个库的CMakeLists.txt正常用add_library定义目标）
2. 在b的CMakeLists.txt中：

   include(FetchContent)
   # 声明依赖a的仓库信息
   FetchContent_Declare(
       a
       GIT_REPOSITORY <你的a库Git仓库URL>
       GIT_TAG <指定版本标签/分支，如v1.0.0>
   )
   # 拉取并构建a
   FetchContent_MakeAvailable(a)
   

3. 在c的CMakeLists.txt中：

   include(FetchContent)
   # 声明依赖a和b的仓库信息
   FetchContent_Declare(
       a
       GIT_REPOSITORY <你的a库Git仓库URL>
       GIT_TAG <指定版本标签/分支>
   )
   FetchContent_Declare(
       b
       GIT_REPOSITORY <你的b库Git仓库URL>
       GIT_TAG <指定版本标签/分支>
   )
   # 批量拉取并构建依赖
   FetchContent_MakeAvailable(a b)
   

优势 #

• 无需手动维护Git子模块，依赖版本统一管理
• FetchContent会自动检测依赖是否已被引入，不会重复定义目标
• 单独构建b时，会自动拉取并构建a，满足独立构建需求
• 符合现代CMake的依赖管理规范

方案3：find_package配合本地构建配置（复用构建产物） #

如果希望复用已构建的库产物，减少重复构建时间，可以让每个库生成CMake配置文件，通过find_package查找本地构建的包：

1. 改造每个库的CMakeLists.txt，添加配置文件生成逻辑（以a为例）：

   add_library(a STATIC [你的源文件])
   
   # 生成目标导出文件
   export(EXPORT aTargets
       FILE "${CMAKE_CURRENT_BINARY_DIR}/aTargets.cmake"
       NAMESPACE a::
   )
   
   # 生成配置文件模板
   include(CMakePackageConfigHelpers)
   configure_package_config_file(
       ${CMAKE_CURRENT_SOURCE_DIR}/aConfig.cmake.in
       ${CMAKE_CURRENT_BINARY_DIR}/aConfig.cmake
       INSTALL_DESTINATION ${CMAKE_CURRENT_BINARY_DIR}
   )
   

   新建aConfig.cmake.in文件，内容为：

   include("${CMAKE_CURRENT_LIST_DIR}/aTargets.cmake")
   

2. 在b的CMakeLists.txt中，优先查找本地已构建的a，找不到再引入子模块：

   # 查找a的本地构建配置
   find_package(a QUIET CONFIG PATHS ${CMAKE_CURRENT_SOURCE_DIR}/a/build NO_DEFAULT_PATH)
   if(NOT a_FOUND)
       add_subdirectory(a)
   endif()
   

3. 在c的CMakeLists.txt中，同样处理a和b的依赖：

   find_package(a QUIET CONFIG PATHS ${CMAKE_CURRENT_SOURCE_DIR}/a/build NO_DEFAULT_PATH)
   if(NOT a_FOUND)
       add_subdirectory(a)
   endif()
   
   find_package(b QUIET CONFIG PATHS ${CMAKE_CURRENT_SOURCE_DIR}/b/build NO_DEFAULT_PATH)
   if(NOT b_FOUND)
       add_subdirectory(b)
   endif()
   

优势 #

• 可以复用已构建的库产物，节省构建时间
• 保持各库的独立构建能力
• 符合CMake标准的包查找机制，扩展性更强

总结推荐 #

• 若想最小化改动现有结构，方案1是最直接有效的选择，完全匹配你的所有限制条件；
• 若想升级到现代化依赖管理，方案2更值得尝试；
• 若需要在多项目间复用构建产物，方案3会更合适。

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