第七章：头文件与路径——include_directories、target_include_directories、路径传递
说到头文件路径，我估计每个C/C++开发者都踩过类似的坑。明明代码逻辑没问题，编译器就是报“找不到头文件”。嗯，说白了就是编译器不知道上哪儿去找那些.h文件。
我个人习惯把项目里的头文件路径管理看作“给编译器画地图”。你画得越清楚，它找得越准。今天咱们就聊聊CMake里怎么画这张地图。
7.1 老派的include_directories
include_directories()是CMake早期就有的命令。它的作用很简单：给当前CMakeLists.txt以及所有子目录的所有目标添加头文件搜索路径。
# 老派写法
include_directories(${PROJECT_SOURCE_DIR}/include)
include_directories(${PROJECT_SOURCE_DIR}/third_party/json/include)
add_executable(my_app main.cpp utils.cpp)
你看，这样写完之后，my_app里所有源文件都能找到include/和third_party/json/include/下的头文件。
所以我现在基本不用include_directories了。除非是那种特别小的、只有一两个目标的玩具项目。
7.2 现代做法：target_include_directories
从CMake 2.8.11开始，官方推荐用target_include_directories()。它把路径绑定到具体的目标上，不会污染全局。
# 现代写法
add_library(my_lib src/lib.cpp include/lib.h)
target_include_directories(my_lib
PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:include>
)
add_executable(my_app main.cpp)
target_link_libraries(my_app PRIVATE my_lib)
这里有个关键概念：PUBLIC、PRIVATE、INTERFACE。我刚开始学的时候也被这三个词绕晕过。其实说白了：
| 关键字 | 对自身的影响 | 对依赖者的影响 |
|---|---|---|
| PRIVATE | 仅自己编译时使用 | 不传递 |
| PUBLIC | 自己编译时使用 | 传递给依赖者 |
| INTERFACE | 自己编译时不使用 | 仅传递给依赖者 |
举个例子：你写了一个日志库，内部用了spdlog。对外暴露的头文件里没有引用spdlog，那spdlog的路径就该设为PRIVATE。如果对外头文件里引用了，那就得设为PUBLIC。
7.3 路径传递的两种模式
路径传递，说白了就是“A库的头文件路径怎么让B库知道”。CMake里主要有两种方式。
7.3.1 通过target_link_libraries隐式传递
这是最推荐的方式。当你用target_link_libraries(B PRIVATE A)时，如果A的target_include_directories用了PUBLIC，那么B自动就能找到A的头文件。
add_library(A a.cpp a.h)
target_include_directories(A PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
add_library(B b.cpp b.h)
target_link_libraries(B PRIVATE A) # B自动获得A的PUBLIC头文件路径
你想想看，这种方式多优雅。依赖关系清晰，路径传递自动完成，不会漏也不会多。
7.3.2 手动传递变量
有些老项目或者特殊场景，会用手动传递变量的方式：
# 不推荐，但偶尔会遇到
set(MY_INCLUDE_DIRS
${PROJECT_SOURCE_DIR}/include
${PROJECT_SOURCE_DIR}/third_party
)
add_library(my_lib ...)
target_include_directories(my_lib PRIVATE ${MY_INCLUDE_DIRS})
add_executable(my_app ...)
target_include_directories(my_app PRIVATE ${MY_INCLUDE_DIRS})
这种方式的问题在于：你得手动维护这个变量，而且它不会自动跟随依赖关系变化。我在一个遗留项目里见过这种写法，每次新增一个第三方库都要改三四个地方，特别容易漏。
7.4 生成器表达式：让路径更灵活
前面代码里出现了$<BUILD_INTERFACE:...>和$<INSTALL_INTERFACE:...>，这就是生成器表达式。它们让路径在不同场景下表现不同。
target_include_directories(my_lib
PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:include>
)
什么意思呢？
- 在构建阶段，路径指向源码目录下的
include - 在安装阶段，路径指向安装目录下的
include
这样做的好处是：你的库安装到系统后，别人用find_package找到它，头文件路径自动变成安装后的位置，不需要手动调整。
7.5 知识体系总览
下面这张图总结了本章的核心逻辑：
7.6 避坑指南
最后分享几个我实战中遇到的坑：
- 路径中有空格：Windows上常见。用双引号包起来，或者用
${CMAKE_CURRENT_SOURCE_DIR}这种变量，CMake会自动处理。 - 相对路径的陷阱：
target_include_directories里写../include，在不同构建目录下可能指向不同的地方。我建议始终用${CMAKE_CURRENT_SOURCE_DIR}拼出绝对路径。 - 忘记加生成器表达式：如果你的库要安装给别人用，一定要加上
$<INSTALL_INTERFACE:...>。否则别人用find_package找到你的库后，头文件路径还是指向你的源码目录——那肯定找不到。
嗯，关于头文件路径，核心就这些。记住一个原则：用target_include_directories，慎用include_directories，路径传递靠target_link_libraries自动完成。这样你的CMake项目会干净很多，也更容易维护。