CMake中target_link_libraries如何区分参数是库名还是目标？

• 静态库的依赖传播特性：静态库没有独立的链接阶段，它的PRIVATE依赖本质上还是会传递到最终的可执行/动态库链接环节。你在B中设置PRIVATE C::C只是说明C的接口不会暴露给B的上游使用者，不代表最终链接时不需要C的二进制文件。
• B的包配置缺少依赖声明：你在编译B的时候本地有find_package(C)生成的C::C导入目标，所以能正常生成B库。但如果你没有在B的CMake包配置（即BConfig.cmake）中声明对C的依赖，那么A项目find_package(B)时，CMake无法识别C::C是导入目标，就会直接把它当成普通库名生成-lC::C的链接参数，ld自然无法识别这个非法的库名。

小提醒：你提供的B的CMakeLists.txt里find_package(C REUQIRED)存在拼写错误，正确写法是find_package(C REQUIRED)，注意修正这个笔误避免额外报错。

你不需要修改A的任何配置，只要调整B的CMake打包逻辑即可，推荐采用以下两种规范方案：

方案一：在B的包配置中自动引入C的依赖（最推荐） #

这是CMake官方推荐的静态库依赖处理方式，完全不需要A感知C的存在：

1. 在B项目的包配置模板（通常是BConfig.cmake.in）中添加以下内容：

include(CMakeFindDependencyMacro)
find_dependency(C REQUIRED)

2. 确保你使用CMake官方的configure_package_config_file来生成B的Config.cmake文件，打包B的时候把这个生成的Config.cmake一起发布。
   当A执行find_package(B)时，会自动执行BConfig.cmake里的find_dependency(C)逻辑，C::C目标会被正常识别，链接时就会用C的正确路径而不是生成-lC::C参数。

方案二：把C的代码合并编译进B #

如果C是小型依赖，你可以直接把C的符号集成到B的静态库中，完全消除B对C的外部依赖：
修改B的CMakeLists.txt，将target_link_libraries(B PRIVATE C::C)替换为：

target_sources(B PRIVATE $<TARGET_OBJECTS:C::C>)

这种方式编译出来的B静态库已经包含了C的所有实现代码，最终链接A的时候不需要再找C，自然不会出现找不到C::C的问题。

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