CMake处理未使用链接库的逻辑及冗余头目录相关疑问

背景场景 #

我正在清理重构一个老旧项目，发现所有CMakeLists.txt文件中的目标都被添加了不必要的链接：

LIST(APPEND ${PROJECT_NAME}_LIBRARIES RecursiveLy_generated_list_with_unnecessarystuff)
target_link_libraries(sample PUBLIC ${${PROJECT_NAME}_LIBRARIES})

将链接列表替换为仅包含必要链接后，编译时间明显缩短。现针对两个疑问解答如下：

1. 当链接的库中符号未被使用时，CMake会如何处理？ #

CMake本身不直接处理未使用符号的逻辑，它的作用是生成构建系统，并将你指定的所有库传递给链接器。实际的行为由链接器和链接选项决定：

• 静态库：链接器默认会扫描静态库的目标文件，仅提取包含当前未定义符号的部分。但即便符号未被使用，链接器仍需逐个扫描你指定的静态库的符号表，这会额外消耗链接时间——这也是清理多余库后编译（链接）速度提升的核心原因之一。开启优化（如-O2）时，现代链接器（GCC ld、Clang lld）会通过--gc-sections等选项自动移除最终可执行文件中未使用的代码段和符号。
• 动态库：链接动态库时，只是在可执行文件中记录依赖关系，不会将动态库代码并入可执行文件。但即便未使用其符号，链接器仍需处理该库的依赖记录，且可执行文件会保留对它的依赖（运行时加载器会尝试加载），同样会增加链接阶段的耗时。

简言之：CMake会如实传递所有指定的库给链接器，多余的库哪怕符号没用，也会拖慢链接速度。

2. 清理包含目录后，CMake是否会因头文件存在符号就判定其被使用（即便未被#include）？ #

不会。CMake不会分析头文件内容来判断符号是否被使用，它仅负责将包含目录传递给编译器。编译器在预处理阶段只会处理被#include显式引入的头文件，未被引用的头文件哪怕在包含目录中，也不会被读取、解析。

清理包含目录带来编译提速的原因包括：

• 缩小了编译器查找头文件的搜索范围，减少文件查找耗时；
• 避免了同名头文件的意外冲突；
• 减少了预编译头的不必要更新（若项目使用预编译头）。

内容的提问来源于stack exchange，提问作者Ivan