5、链接库：target_link_libraries 的现代用法

链接库这件事，说白了就是让你的代码能调用别人写好的功能。静态库、动态库，还有那个让人头疼的传递性——嗯，今天咱们一次性说清楚。

我个人习惯把 target_link_libraries 看作是 CMake 里最核心的命令之一。为什么？因为它直接决定了你的目标（target）能用到哪些库，以及这些库的依赖关系怎么传递。搞不懂这个，你的构建系统迟早会变成一团乱麻。

5.1 静态库 vs 动态库：先搞清楚区别

在讲链接之前，咱们得先明确静态库和动态库的区别。我在项目中遇到过不少新手，上来就问「我该用静态还是动态？」——其实没有标准答案，得看场景。

特性	静态库（.a / .lib）	动态库（.so / .dll）
链接时机	编译时直接嵌入可执行文件	运行时加载
文件大小	可执行文件变大	可执行文件较小
部署	单文件，方便	需要附带 .so / .dll
更新	需要重新编译整个程序	替换库文件即可
内存占用	每个进程一份	多个进程可共享

你想想看，如果你写的是一个命令行小工具，静态库就挺好，扔出去一个文件完事。但如果你做的是大型系统，比如游戏引擎或者服务器，动态库更灵活——热更新、插件化都靠它。

5.2 target_link_libraries 的基本用法

现代 CMake 里，链接库的写法非常直观。咱们直接看代码：

# 创建一个可执行文件
add_executable(my_app main.cpp)

# 链接一个静态库
target_link_libraries(my_app PRIVATE my_static_lib)

# 链接一个动态库
target_link_libraries(my_app PRIVATE my_shared_lib)

# 同时链接多个库
target_link_libraries(my_app
    PRIVATE
        my_static_lib
        my_shared_lib
        pthread
)

这里的关键字 PRIVATE、PUBLIC、INTERFACE 决定了链接的传递性。我刚开始用 CMake 时，这三个关键字把我绕晕了好一阵子。咱们一个一个说。

5.3 链接传递性：PRIVATE、PUBLIC、INTERFACE

为什么会需要传递性？举个例子：你的库 A 依赖了库 B，然后你的可执行文件 my_app 链接了 A。那么 my_app 需不需要知道 B 的存在？

答案取决于 A 是怎么暴露 B 的。这就是传递性的核心。

来看个实际例子：

# 库 A 依赖了库 B
add_library(A STATIC a.cpp)
add_library(B STATIC b.cpp)

# 情况1：A 内部用了 B，但对外不暴露 B 的接口
target_link_libraries(A PRIVATE B)
# my_app 链接 A 时，不需要知道 B
target_link_libraries(my_app PRIVATE A)  # 正确

# 情况2：A 的公共头文件里包含了 B 的东西
target_link_libraries(A PUBLIC B)
# my_app 链接 A 时，必须也能找到 B
target_link_libraries(my_app PRIVATE A)  # 自动传递了 B

# 情况3：A 是个纯接口库，自己不需要 B，但要求使用者必须链接 B
target_link_libraries(A INTERFACE B)
# my_app 链接 A 时，必须也链接 B
target_link_libraries(my_app PRIVATE A)  # 自动传递了 B

我曾经在一个项目里犯过这样的错：把一个 PUBLIC 写成了 PRIVATE，结果编译通过，链接报了一堆 undefined reference。排查了半天才发现是传递性没搞对。嗯，从那以后我每次写 target_link_libraries 都会多看一眼关键字。

5.4 现代 CMake 的推荐写法

我个人建议，尽量用 PRIVATE。为什么？因为信息隐藏是好习惯。你的库内部依赖了什么，那是你的实现细节，没必要暴露给使用者。除非你的公共头文件确实引用了依赖库的类型或函数，才用 PUBLIC。

至于 INTERFACE，它通常用在头文件库（header-only library）或者纯接口定义的场景。比如：

# 一个纯头文件的库
add_library(my_header_only INTERFACE)
target_include_directories(my_header_only INTERFACE include)
target_link_libraries(my_header_only INTERFACE Eigen3)

这里 my_header_only 自己不需要编译，但它要求所有链接它的人必须能链接到 Eigen3。

5.5 链接系统库和第三方库

除了自己构建的库，我们还经常需要链接系统库或者第三方库。现代 CMake 推荐用 find_package 来查找：

# 查找系统库
find_package(Threads REQUIRED)
target_link_libraries(my_app PRIVATE Threads::Threads)

# 查找第三方库（比如 OpenCV）
find_package(OpenCV REQUIRED)
target_link_libraries(my_app PRIVATE ${OpenCV_LIBS})

注意，用 find_package 找到的库，很多已经提供了 CMake 目标（比如 Threads::Threads），直接用目标名链接是最安全的做法。为什么？因为目标名会自带头文件路径、编译选项等所有信息。

5.6 避坑指南：链接顺序

嗯，这里要特别提醒一下。链接器在处理库的时候是有顺序的。如果你有循环依赖，或者顺序不对，可能会报 undefined reference。

我曾经在一个大型项目里，因为链接顺序问题折腾了整整一天。最后发现是库 A 依赖库 B，但我在链接时把 B 写在了 A 前面。链接器从左到右处理，遇到 A 时发现需要 B 的符号，但 B 已经被处理过了——于是报错。

解决办法很简单：

# 正确的顺序：被依赖的库放在后面
target_link_libraries(my_app PRIVATE A B)
# 如果 A 依赖 B，B 必须在 A 后面

# 或者用 target_link_libraries 的传递性自动处理
target_link_libraries(A PRIVATE B)
target_link_libraries(my_app PRIVATE A)  # 自动带上 B

5.7 知识体系总览

下面这张图总结了 target_link_libraries 的核心知识结构，你可以把它当作速查表：

5.8 总结

target_link_libraries 是现代 CMake 里最常用的命令之一。记住三点：

• 分清静态和动态：根据你的部署和更新需求选择
• 用好传递性：PRIVATE 是默认首选，PUBLIC 用于暴露接口，INTERFACE 用于纯头文件库
• 用目标名链接：尽量用 find_package 找到的目标名，而不是变量名

链接库这件事，说白了就是管理依赖。依赖管理好了，你的构建系统就稳了。依赖搞乱了，嗯，你会花很多时间在莫名其妙的链接错误上。希望今天的内容能帮你少踩几个坑。

---