接口库与别名：INTERFACE库、ALIAS目标、纯头文件库、传递依赖

嗯，这一章我们来聊聊 CMake 里一个特别实用、但很多人一开始会绕开的概念——接口库（INTERFACE Library）和别名目标（ALIAS Target）。

说实话，我刚开始用 CMake 那会儿，也觉得这东西可有可无。直到有一次，我在一个大型 C++ 项目里，需要管理几十个纯头文件的库，还要处理一堆复杂的依赖关系……那时候我才发现，没有接口库和别名，你的 CMakeLists.txt 会变得又臭又长，维护起来简直想哭。

所以今天，咱们就把这块彻底讲透。

什么是 INTERFACE 库？

先问个问题：你有没有遇到过这种情况？

• 你写了一个纯头文件的库（比如 Eigen、nlohmann/json 这种）
• 它不需要编译，只需要包含头文件
• 但它需要设置一些编译选项、包含路径、甚至链接其他库

如果用普通的 add_library，CMake 会默认生成一个编译目标，然后发现没有源文件，就会报错。这时候，INTERFACE 库就是为你量身定做的。

语法很简单：

add_library(my_header_only INTERFACE)
target_include_directories(my_header_only INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_compile_definitions(my_header_only INTERFACE USE_MY_LIBRARY=1)

你看，这里的关键字是 INTERFACE。它告诉 CMake：这个库不需要编译，但其他目标链接它时，要继承这些属性。

纯头文件库的最佳实践

我个人习惯，把所有纯头文件的库都用 INTERFACE 来定义。为什么呢？

• 清晰：一眼就能看出这个库不需要编译
• 高效：CMake 不会尝试去编译它，节省构建时间
• 干净：不会生成多余的 .a 或 .so 文件

举个例子，假设你有一个 math_utils 库，全是模板和 inline 函数：

# CMakeLists.txt
add_library(math_utils INTERFACE)
target_include_directories(math_utils INTERFACE 
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
    $<INSTALL_INTERFACE:include>
)
target_link_libraries(math_utils INTERFACE Eigen3::Eigen)

这里我用了生成器表达式 $<BUILD_INTERFACE> 和 $<INSTALL_INTERFACE>，这是为了让库在构建时和安装后都能正确找到头文件。嗯，这个技巧我在项目里用过很多次，非常实用。

ALIAS 目标：给你的库起个“别名”

接下来聊聊别名目标。说白了，ALIAS 就是给一个已有的目标起个新名字。

你可能会问：为什么要多此一举？

我举个例子。你在一个大型项目里，有一个核心库叫 core，但你想让外部使用者通过 MyProject::core 来引用它。这时候，别名就派上用场了：

add_library(MyProject::core ALIAS core)

这样，其他模块就可以用 target_link_libraries(other_lib MyProject::core) 来依赖它。这种命名方式（项目名::模块名）是 CMake 社区的惯例，也是现代 CMake 的推荐做法。

add_library(my_header_only INTERFACE)
add_library(MyProject::headers ALIAS my_header_only)

传递依赖：依赖的依赖怎么处理？

这是很多新手容易踩坑的地方。假设你有三个库：

• A 依赖 B
• B 依赖 C
• 你想让 A 自动获得 C 的包含路径和链接库

这就是传递依赖。在 CMake 里，通过 target_link_libraries 的 PUBLIC 和 INTERFACE 关键字来控制。

看个例子：

add_library(C STATIC c.cpp)
target_include_directories(C PUBLIC include_c)

add_library(B STATIC b.cpp)
target_link_libraries(B PUBLIC C)  # B 公开依赖 C
target_include_directories(B PUBLIC include_b)

add_library(A STATIC a.cpp)
target_link_libraries(A PUBLIC B)  # A 公开依赖 B
# 现在 A 自动获得了 B 和 C 的包含路径！

为什么会这样？因为 PUBLIC 关键字表示：这个依赖关系不仅要给自己用，还要传递给链接自己的目标。所以 A 链接了 B，就自动继承了 B 的所有 PUBLIC 依赖——也就是 C。

接口库与传递依赖的结合

接口库和传递依赖结合起来，威力巨大。比如你有一个纯头文件的日志库 logger，它依赖一个字符串处理库 string_utils（也是纯头文件）：

add_library(string_utils INTERFACE)
target_include_directories(string_utils INTERFACE include/string_utils)

add_library(logger INTERFACE)
target_include_directories(logger INTERFACE include/logger)
target_link_libraries(logger INTERFACE string_utils)  # 传递依赖

# 使用者只需要链接 logger，自动获得 string_utils
target_link_libraries(my_app logger)

这样，my_app 只需要链接 logger，就能同时获得 logger 和 string_utils 的头文件路径。是不是很清爽？

知识体系图

下面这张图，帮你理清本章的核心逻辑：

避坑指南

最后，分享几个我踩过的坑：

• 别名不能用于 add_custom_target：ALIAS 只支持 add_library 和 add_executable 创建的目标。如果你试图给自定义目标起别名，CMake 会直接报错。
• INTERFACE 库不能有源文件：如果你不小心给 INTERFACE 库加了源文件，CMake 会忽略它们。我一开始以为会报错，结果编译通过了但链接时找不到符号……排查了好久。
• 传递依赖的循环问题：A 依赖 B，B 依赖 A，这种循环依赖在 CMake 里是不允许的。设计库的时候要避免这种情况。
• 生成器表达式要小心：在 INTERFACE 库的 target_include_directories 里用生成器表达式时，要确保语法正确。我曾经少写了一个 $，结果头文件路径死活不对。

好了，这一章的内容就到这里。接口库和别名，说白了就是让 CMake 项目更模块化、更清晰。你想想看，当你的项目有几十个库的时候，一个清晰的命名和依赖管理，能省下多少排查问题的时间？