19、CMake接口库与对象库：INTERFACE库、OBJECT库、纯头文件库管理
说实话，很多C++开发者刚开始接触CMake时，对库的理解就停留在「静态库(.a/.lib)」和「动态库(.so/.dll)」上。这当然没错，但CMake还提供了两种特殊的库类型——INTERFACE库和OBJECT库。它们不生成传统的二进制产物，却在现代C++项目中扮演着极其重要的角色。
我个人习惯把这两种库叫做「轻量级库」。它们解决了一个很实际的问题：当你的代码不需要编译，或者你想精细控制编译流程时，该怎么办？
19.1 纯头文件库的困境
先聊聊纯头文件库。你想想看，很多现代C++库（比如Eigen、nlohmann/json、Catch2）都是纯头文件的。用户只需要#include一下就能用，省去了链接的麻烦。
但问题来了：在CMake中怎么管理这种库？
你不能用add_library(my_header_lib STATIC ...)，因为根本没有源文件要编译。你也不能用add_library(my_header_lib SHARED ...)，同理。那怎么办？
嗯，这里就要请出我们的主角——INTERFACE库。
核心概念：INTERFACE库是一个「虚拟」的库目标。它不编译任何源文件，不生成任何二进制产物。它只负责传递编译需求——头文件路径、宏定义、编译选项、链接库依赖等。
我在项目中遇到过好几次这样的情况：团队新人把纯头文件库用STATIC方式定义，结果发现CMake报错说「没有源文件」。其实只要换成INTERFACE，一切就顺了。
19.2 INTERFACE库实战
来看一个典型的例子。假设你有一个纯头文件的数学工具库，目录结构如下：
my_math_tools/
├── CMakeLists.txt
├── include/
│ └── my_math/
│ ├── vector.h
│ └── matrix.h
└── examples/
└── main.cpp在CMakeLists.txt中，你应该这样定义：
# 定义一个INTERFACE库
add_library(my_math_tools INTERFACE)
# 指定头文件目录（注意：INTERFACE关键字）
target_include_directories(my_math_tools
INTERFACE
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:include>
)
# 如果需要C++17标准
target_compile_features(my_math_tools
INTERFACE
cxx_std_17
)
# 如果依赖其他库
target_link_libraries(my_math_tools
INTERFACE
Eigen3::Eigen
)注意看，所有命令都用了INTERFACE关键字。这意味着这些属性只会传递给链接这个库的目标，而不会作用于库本身——因为库本身根本没有编译过程。
小技巧：使用$<BUILD_INTERFACE>和$<INSTALL_INTERFACE>生成器表达式，可以优雅地区分构建时和安装后的头文件路径。这是我个人非常推荐的做法。
然后，其他目标就可以这样链接：
add_executable(main examples/main.cpp)
target_link_libraries(main PRIVATE my_math_tools)就这么简单。main目标会自动获得头文件路径、C++标准要求、以及Eigen的依赖。
19.3 OBJECT库：编译但不链接
接下来聊聊OBJECT库。这东西比INTERFACE库要「重」一点，但比静态库要「轻」一点。
OBJECT库会编译源文件，生成目标文件(.o/.obj)，但不打包成静态库或动态库。说白了，它就是一个「半成品」——编译好的目标文件集合，等着被其他目标吞进去。
为什么会需要这种东西？我举个例子。
假设你有一个项目，需要构建两个可执行文件：app_debug和app_release。它们共享大部分代码，但部分源文件需要不同的编译选项（比如一个带调试符号，一个带优化）。
如果用静态库，你得编译两次共享代码——一次给debug用，一次给release用。如果用OBJECT库，你可以只编译一次共享代码，然后把目标文件分别喂给两个可执行文件。
注意：OBJECT库的源文件只会被编译一次。如果你需要不同的编译选项，那OBJECT库就不太适合了。这种情况下，我建议你还是用静态库或者直接列出源文件。
来看一个实际例子：
# 定义OBJECT库
add_library(common_objects OBJECT
src/utils.cpp
src/logger.cpp
src/config.cpp
)
# 设置编译选项（注意：用PUBLIC或PRIVATE，不是INTERFACE）
target_include_directories(common_objects
PUBLIC
include
)
target_compile_definitions(common_objects
PRIVATE
USE_LOGGING
)
# 创建两个可执行文件，共享OBJECT库的目标文件
add_executable(app_debug
src/main.cpp
$<TARGET_OBJECTS:common_objects>
)
add_executable(app_release
src/main.cpp
$<TARGET_OBJECTS:common_objects>
)
# 可以分别设置不同的编译选项
target_compile_definitions(app_debug PRIVATE DEBUG_MODE)
target_compile_definitions(app_release PRIVATE RELEASE_MODE)关键语法是$<TARGET_OBJECTS:common_objects>，它会展开成OBJECT库生成的所有目标文件路径。这样，两个可执行文件就共享了同一份编译好的目标文件。
19.4 一张图看懂三种库
为了帮你理清思路，我画了一张对比图：
19.5 避坑指南与最佳实践
讲完了基础用法，我来分享一些实战中积累的经验。
19.5.1 INTERFACE库的常见误区
误区一：在INTERFACE库中使用PRIVATE关键字
INTERFACE库没有编译过程，所以PRIVATE关键字没有意义。所有属性都必须是INTERFACE（传递给下游）或PUBLIC（同时传递给下游和自身，但自身不编译）。
我曾经看到有人这样写：target_include_directories(my_header_lib PRIVATE include)。这其实不会生效，因为INTERFACE库根本没有「私有」的头文件搜索路径。正确的做法是用INTERFACE关键字。
误区二：忘记处理安装路径
纯头文件库安装时，需要把头文件复制到正确的位置。别忘了在install命令中处理：
install(
DIRECTORY include/
DESTINATION include
)
install(
TARGETS my_math_tools
EXPORT MyMathToolsConfig
)19.5.2 OBJECT库的注意事项
OBJECT库虽然好用，但有几个坑要小心：
- 编译选项固定：OBJECT库的源文件只编译一次。如果你需要同一个源文件用不同编译选项编译两次，那OBJECT库不适合你。
- 生成器表达式限制：有些生成器表达式在OBJECT库中可能不按预期工作。我建议在复杂场景下先做个小测试。
- 跨平台问题：某些IDE（如Visual Studio）对OBJECT库的支持可能不如Makefile完美。如果你在Windows上遇到奇怪的问题，可以试试换成静态库。
我的建议：OBJECT库最适合的场景是——你有多个可执行文件或共享库，它们共享大量代码，且这些代码的编译选项完全相同。这种情况下，OBJECT库能显著减少编译时间。
19.5.3 什么时候用哪种库？
| 场景 | 推荐库类型 | 原因 |
|---|---|---|
| 纯头文件库（无源文件） | INTERFACE | 不编译，只传递依赖 |
| 有源文件，需要打包分发 | STATIC 或 SHARED | 生成标准二进制库文件 |
| 多个目标共享同一份编译产物 | OBJECT | 避免重复编译，节省时间 |
| 需要不同编译选项的共享代码 | STATIC（每个配置编译一次） | OBJECT库编译选项固定 |
| 接口库（只有头文件和依赖声明） | INTERFACE | 最轻量，无二进制产物 |
19.6 总结
INTERFACE库和OBJECT库是CMake工具箱里的两把「瑞士军刀」。它们不像静态库和动态库那样广为人知，但在特定场景下能发挥奇效。
我个人在管理大型项目时，几乎每个项目都会用到INTERFACE库——要么用来封装纯头文件依赖，要么用来定义接口约束。OBJECT库则用得少一些，但在构建时间优化上立过不少功。
记住一句话：选对库类型，比写对代码更重要。一个合理的库结构，能让你的CMakeLists.txt更清晰，构建过程更高效，团队协作更顺畅。