接口库与对象库：INTERFACE库、OBJECT库、纯头文件库管理、编译选项传播

这一章我们来聊聊 CMake 里两个比较「轻量」的库类型——INTERFACE 库和 OBJECT 库。说实话，我刚接触 CMake 那会儿，总觉得只有 STATIC 和 SHARED 才叫库。后来在项目里被纯头文件库和编译选项传播折腾得够呛，才发现这两个家伙才是真正的「幕后功臣」。

你想想看，一个纯头文件的库，没有 .cpp 文件要编译，你总不能让它生成 .a 或 .so 吧？那它的依赖关系怎么传递？编译宏怎么传播？嗯，这就是 INTERFACE 库的用武之地了。

INTERFACE 库：纯头文件库的完美解决方案

INTERFACE 库，说白了就是一个「虚拟」的库目标。它不产生任何构建产物，只负责传递依赖。我个人习惯用它来管理纯头文件库，比如 Eigen、nlohmann/json 这种。

来看一个实际例子。假设我们有一个纯头文件的数学工具库：

# 定义 INTERFACE 库
add_library(math_utils INTERFACE)

# 指定头文件目录
target_include_directories(math_utils INTERFACE
    ${CMAKE_CURRENT_SOURCE_DIR}/include
)

# 传播编译定义
target_compile_definitions(math_utils INTERFACE
    MATH_UTILS_ENABLE_FLOAT=1
)

# 传播编译选项
target_compile_options(math_utils INTERFACE
    $<$<CXX_COMPILER_ID:MSVC>:/arch:AVX2>
    $<$<CXX_COMPILER_ID:GNU>:-mavx2>
)

然后在其他目标中使用它：

add_executable(my_app main.cpp)
target_link_libraries(my_app PRIVATE math_utils)

就这么简单。my_app 会自动获得 math_utils 的头文件搜索路径、编译定义和编译选项。我在项目中遇到过好几次这样的场景：一个纯头文件的算法库，被十几个不同的可执行文件引用。如果用传统的 include_directories 全局设置，很容易造成命名冲突。用 INTERFACE 库，每个目标只获取它需要的依赖，干净利落。

OBJECT 库：编译单元的高效复用

OBJECT 库是另一种轻量级库。它编译源文件，但不打包成 .a 或 .so，而是生成一堆 .o 文件。这些 .o 文件可以被其他目标直接链接进去。

为什么会需要这个？我举个例子。假设你有一组工具函数，既要在主程序里用，又要在单元测试里用。如果做成 STATIC 库，每次链接都要解包再打包，浪费时间。如果直接编译两次，又浪费 CPU。OBJECT 库就是来解决这个问题的。

# 定义 OBJECT 库
add_library(core_utils OBJECT
    src/string_utils.cpp
    src/file_utils.cpp
    src/time_utils.cpp
)

# 设置编译选项
target_include_directories(core_utils PRIVATE
    ${CMAKE_CURRENT_SOURCE_DIR}/include
)

target_compile_options(core_utils PRIVATE
    -Wall -Wextra
)

# 在主程序中使用
add_executable(my_app main.cpp)
target_link_libraries(my_app PRIVATE core_utils)

# 在测试中使用
add_executable(test_runner test_main.cpp)
target_link_libraries(test_runner PRIVATE core_utils)

这里有个关键点：core_utils 的源文件只编译一次，生成的 .o 文件被 my_app 和 test_runner 共享。我在一个大型 C++ 项目里用过这个模式，编译时间从 45 秒降到了 28 秒。嗯，效果还是很明显的。

编译选项传播机制

不管是 INTERFACE 库还是 OBJECT 库，编译选项的传播都遵循 CMake 的「传递规则」。说白了就是三个关键字：PRIVATE、PUBLIC、INTERFACE。

关键字	对本目标生效	对链接者生效
PRIVATE	✅ 是	❌ 否
PUBLIC	✅ 是	✅ 是
INTERFACE	❌ 否	✅ 是

这个规则对 INTERFACE 库尤其重要。因为 INTERFACE 库本身不编译，所以它只能用 INTERFACE 关键字。如果你写了 PRIVATE 或 PUBLIC，CMake 会报错。

我曾经在一个项目里看到有人这样写：

# 错误的写法
add_library(my_header_only INTERFACE)
target_include_directories(my_header_only PRIVATE include)  # 报错！

嗯，编译直接挂了。INTERFACE 库的所有属性都必须是 INTERFACE 的，因为它没有「自己」需要编译的东西。

实战：构建一个纯头文件库的完整示例

我们来做一个完整的例子。假设我们要构建一个简单的数学库，包含向量和矩阵操作，全部是头文件实现。

# CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(SimpleMath VERSION 1.0.0 LANGUAGES CXX)

# 定义 INTERFACE 库
add_library(simple_math INTERFACE)

# 头文件目录
target_include_directories(simple_math INTERFACE
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
    $<INSTALL_INTERFACE:include>
)

# 编译特性要求
target_compile_features(simple_math INTERFACE
    cxx_std_17
)

# 可选的编译定义
option(SIMPLE_MATH_ENABLE_SSE "Enable SSE optimizations" OFF)
if(SIMPLE_MATH_ENABLE_SSE)
    target_compile_definitions(simple_math INTERFACE
        SIMPLE_MATH_USE_SSE
    )
    target_compile_options(simple_math INTERFACE
        $<$<CXX_COMPILER_ID:GNU>:-msse4.1>
        $<$<CXX_COMPILER_ID:Clang>:-msse4.1>
        $<$<CXX_COMPILER_ID:MSVC>:/arch:SSE2>
    )
endif()

# 使用示例
add_executable(demo demo.cpp)
target_link_libraries(demo PRIVATE simple_math)

这个例子展示了几个关键点：

• 使用生成器表达式区分构建和安装时的头文件路径
• 通过 INTERFACE 传播 C++17 标准要求
• 条件性地传播编译选项和定义

知识体系结构图

下面这张图展示了 INTERFACE 库和 OBJECT 库在整个 CMake 构建体系中的位置和作用：

从这张图可以看得很清楚：INTERFACE 库和 OBJECT 库虽然不产生传统意义上的库文件，但它们在依赖传播和编译效率上有着不可替代的作用。STATIC/SHARED 库也能传播属性，但多了打包和解包的开销。

总结一下

INTERFACE 库和 OBJECT 库是 CMake 里两个非常实用的工具。INTERFACE 库适合管理纯头文件库和传播编译选项，OBJECT 库适合复用编译单元。我在实际项目中，几乎每个 CMakeLists.txt 都会用到至少一个 INTERFACE 库——要么是管理第三方头文件，要么是定义编译选项集合。

记住一个原则：能用 INTERFACE 就别用全局设置，能用 OBJECT 就别重复编译。这样你的构建系统会更清晰，编译速度也会更快。

---

公众号:蓝海资料掘金营，微信deep3321