CMake项目结构最佳实践咨询：依赖冲突与优化方案抉择

优先选择「顶层CMake判断是否为顶层项目」方案 #

这个方案是CMake社区的标准实践，既能保持项目结构的完整性，又能彻底解决依赖冲突问题，同时维护成本远低于拆分项目的方案。

具体实现步骤 #

1. 顶层CMake条件判断
   在你的myLib/CMakeLists.txt中，仅当项目作为顶层构建时，才引入示例、测试及对应的开发依赖（如googletest）：

cmake_minimum_required(VERSION 3.14)
project(myLib)

# 始终构建核心库
add_subdirectory(src)

# 仅当自身是顶层项目时，构建示例和测试
if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
    add_subdirectory(examples)
    add_subdirectory(googletest)
    add_subdirectory(test)
endif()

2. 公共依赖（spdlog）的优先级处理
   在src/CMakeLists.txt中，优先使用主项目或系统提供的依赖版本，仅在自身作为顶层项目且找不到依赖时，才启用自带的submodule：

# 优先查找系统/主项目提供的spdlog
find_package(spdlog QUIET)
if(NOT spdlog_FOUND)
    # 找不到时才使用自带的submodule
    add_subdirectory(${PROJECT_SOURCE_DIR}/spdlog)
endif()

# 链接核心库与spdlog
target_link_libraries(myLib_core PRIVATE spdlog::spdlog)

3. 专有库的处理
   由于专有库是核心库的强依赖且主项目大概率没有，直接在src/CMakeLists.txt中引入自带的submodule即可：

add_subdirectory(${PROJECT_SOURCE_DIR}/proprietaryLib)
target_link_libraries(myLib_core PRIVATE proprietaryLib::proprietaryLib)

两种方案对比 #

方案一：拆分库与示例/测试为独立项目 #

• 优点：核心库的依赖完全干净，不会将测试、示例的开发依赖带入主项目
• 缺点：需要维护多个独立仓库，开发时需同步多个仓库的版本，协作和日常迭代成本极高，仅适合核心库与测试/示例完全独立、且有专门团队维护的极端场景

方案二：顶层CMake条件判断 #

• 优点：项目结构统一，开发时无需切换仓库；仅在自身作为顶层项目时才构建非核心内容，彻底避免依赖冲突；维护成本低，符合CMake最佳实践
• 缺点：需要编写少量条件判断代码，但逻辑简单易懂，几乎没有维护负担

其他可选优化方案 #

如果希望进一步简化依赖管理，可以考虑用CMake的FetchContent替代git submodule来管理spdlog和googletest：

# 在顶层CMake中仅当作为顶层项目时，用FetchContent拉取依赖
if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
    include(FetchContent)
    FetchContent_Declare(
        googletest
        GIT_REPOSITORY https://github.com/google/googletest.git
        GIT_TAG release-1.12.1
    )
    FetchContent_MakeAvailable(googletest)
    
    FetchContent_Declare(
        spdlog
        GIT_REPOSITORY https://github.com/gabime/spdlog.git
        GIT_TAG v1.11.0
    )
    FetchContent_MakeAvailable(spdlog)
endif()

这种方式无需手动管理submodule，CMake会自动拉取对应版本的依赖，且同样能保证主项目优先使用自身的依赖配置。

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