如何为存在嵌套依赖的CMake项目创建Git嵌套仓库？

针对你提到的主项目与Lib B都依赖Lib A的场景，在不使用Conan这类包管理器的前提下，有以下几种实用方案：

1. 全局/本地缓存式安装Lib A #

将Lib A编译完成后，安装到系统全局路径（比如Linux的/usr/local/lib、Windows的C:\Program Files），或在本地创建统一的依赖缓存目录（如~/project-deps）。之后在主项目和Lib B的CMake配置中，通过find_package(LibA REQUIRED)来查找已安装的Lib A。

• 优点：主项目与Lib B均可独立构建，不会重复引入代码；无需额外版本管理操作。
• 缺点：需手动维护Lib A的版本一致性，多项目场景下可能出现版本冲突；团队协作时需统一依赖版本与安装路径。

2. Git Submodule优化方案 #

如果倾向用Submodule，可避免重复添加：在主项目中添加Lib A作为Submodule，同时给Lib B添加CMake选项（如USE_EXTERNAL_LIBA）。当Lib B随主项目构建时，通过相对路径引用主项目里的Lib A；当Lib B需要独立构建时，允许用户指定外部的Lib A路径。
示例Lib B的CMake配置：

option(USE_EXTERNAL_LIBA "使用外部LibA而非主项目中的实例" OFF)

if(USE_EXTERNAL_LIBA)
  find_package(LibA REQUIRED)
else()
  # 根据实际目录结构调整相对路径，示例为主项目LibA路径是../liba
  add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/../liba ${CMAKE_BINARY_DIR}/liba)
endif()

• 优点：兼顾主项目的统一依赖管理与Lib B的独立构建能力；Submodule可精准控制Lib A版本。
• 缺点：目录结构变动时需调整相对路径；团队成员需正确初始化Submodule。

3. 软链接源码引用 #

在Lib B的目录下，创建指向主项目中Lib A的软链接（Windows用mklink命令，Linux/macOS用ln -s命令），让Lib B编译时直接复用主项目的Lib A源码。当需要独立构建Lib B时，替换软链接为单独的Lib A源码目录即可。

• 优点：无需额外工具，代码引用逻辑简单；主项目与Lib B的Lib A代码自动同步。
• 缺点：软链接在跨平台协作中存在兼容性问题（如Windows需管理员权限创建）；需手动维护链接正确性。

4. CMake FetchContent模块 #

利用CMake原生的FetchContent模块，在主项目和Lib B中配置拉取指定版本的Lib A源码，通过设置FETCHCONTENT_BASE_DIR指定统一缓存目录，避免重复下载。
示例CMake配置：

include(FetchContent)
FetchContent_Declare(
  liba
  GIT_REPOSITORY https://your-git-repo/liba.git
  GIT_TAG v1.0.0 # 指定LibA的版本标签
)
FetchContent_MakeAvailable(liba)

主项目中可统一设置缓存目录：

set(FETCHCONTENT_BASE_DIR ${CMAKE_SOURCE_DIR}/.deps CACHE PATH "统一依赖缓存目录")

• 优点：CMake原生支持，无需额外工具；自动处理版本拉取，统一缓存节省资源。
• 缺点：首次构建需依赖网络下载源码；Lib B独立构建时需确保版本配置与主项目一致。

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