CMake嵌套库依赖场景如何配置以消除重复链接冗余

问题根源 #

你当前使用的是传统CMake的全局变量配置模式，存在两个核心问题：

• 全局命令include_directories只会给当前目录及子目录的target加头文件搜索路径，无法携带依赖传递属性
• 未通过target的链接控制属性标记依赖的传递范围，加上libB的配置本身存在不规范写法，才需要在项目A中重复配置间接依赖libC。
  另外你贴出的libB配置存在明显错误：在libB的构建/包配置中直接操作${PROJECT_NAME}属于污染上层的写法，此时${PROJECT_NAME}指向引入libB的上层项目A，相当于libB隐式修改上层配置，既不可控也无法实现依赖的正确透传。

规范配置方案（基于现代CMake 3.0+ 目标导向模型） #

核心逻辑是：所有编译、链接属性绑定到具体target，通过PUBLIC/PRIVATE/INTERFACE链接属性自动传递依赖，上层项目不需要手动处理间接依赖。

第一步：修正libB的配置 #

libB作为中间依赖，需要把自身对libC的依赖标记为可传递，并且只操作自身的target，不要修改上层项目配置：

# 查找依赖libC，不需要调用全局include_directories
find_package(libC REQUIRED)

# 定义libB自身的target，命名空间格式是现代CMake包的标准写法
# 如果是源码编译libB就用下面的写法，指定源文件
add_library(libB::libB src/libB.cpp ...)
# 如果是已经编译好的预编译库，就用导入库形式
# add_library(libB::libB IMPORTED)
# set_target_properties(libB::libB PROPERTIES IMPORTED_LOCATION <libB库文件路径>)

# 配置libB自身的头文件搜索路径，PUBLIC属性表示依赖libB的target会自动继承该路径
target_include_directories(libB::libB
    PUBLIC
        $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> # 源码构建时的头文件路径
        $<INSTALL_INTERFACE:include> # 安装后对外暴露的头文件路径
)

# 关键：链接libC时使用PUBLIC属性，把libC的所有属性（头文件路径、链接库、编译选项等）传递给链接libB的上层target
target_link_libraries(libB::libB PUBLIC libC::libC)

# 安装导出时把libB的依赖关系一并导出，确保find_package(libB)时能自动加载依赖信息
install(TARGETS libB EXPORT libBTargets
    LIBRARY DESTINATION lib
    ARCHIVE DESTINATION lib
    RUNTIME DESTINATION bin
    INCLUDES DESTINATION include
)
install(EXPORT libBTargets
    NAMESPACE libB::
    DESTINATION lib/cmake/libB
)

如果libB是第三方提供的预编译库，只要它的包配置遵循现代CMake规范，本身已经携带传递依赖信息，不需要手动修改。

第二步：简化项目A的配置 #

修正libB的配置后，项目A完全不需要单独查找、配置libC，所有依赖属性会通过libB的target自动传递：

# 建议使用3.10以上的CMake稳定版本，对现代target特性支持更完善
cmake_minimum_required(VERSION 3.10)
project(A)

# 仅需要查找libB，find_package过程会自动触发查找它依赖的libC
find_package(libB REQUIRED)

add_executable(${PROJECT_NAME} src/main.cpp ...)
# 仅需要链接libB的target，自动继承libB、libC的所有编译链接属性，不需要额外配置libC
target_link_libraries(${PROJECT_NAME} PRIVATE libB::libB)

关键规则说明 #

• 弃用全局命令：不要再用include_directories、link_directories这类全局作用域的命令，所有头文件路径、链接库、编译选项都通过target_*系列命令绑定到具体target，避免全局污染。
• 链接属性选择规则：
  • PRIVATE：依赖仅在当前target的内部实现中使用，不会暴露给上层，不需要透传
  • PUBLIC：当前target的头文件中暴露了该依赖的内容（比如函数参数用了libC的类型、公开接口返回libC的对象、继承了libC的类），上层编译时需要用到该依赖，会自动透传
  • INTERFACE：当前target本身是头文件-only库，不需要编译二进制，仅用来把依赖传递给上层
• 优先使用带命名空间的导入target（比如libB::libB、libC::libC），不要使用传统find_package返回的${libB_LIBRARY}、${libB_INCLUDE_DIR}这类零散变量，这类变量不会携带传递依赖信息。
• 如果遇到第三方库没有提供现代CMake target的情况，可以在find_package之后手动包装一个INTERFACE target，补全对应的头文件路径、依赖关系，避免在每个上层项目中重复配置。

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