CMake 强制重新编译的3种实用方法

1. 为什么你的 TIMESTAMP 总是不更新？

你是不是也遇到过这种头疼的情况？项目明明重新构建了，但程序里打印出来的编译时间 __TIMESTAMP__ 却还是上次的，一点都没变。你反复检查代码，确认文件已经保存，甚至重启了IDE，但那个时间戳就像被冻住了一样，固执地停留在过去。

这其实不是CMake的bug，而是你对它的构建机制理解上的一点点偏差。__TIMESTAMP__ 这个宏，是C/C++编译器（比如GCC或Clang）在编译单个源文件的那个瞬间，读取该源文件的最后修改时间，然后生成的一个字符串。关键在于“编译单个源文件”和“最后修改时间”。

CMake是一个构建系统生成器，它本身不负责编译，它负责生成Makefile或Ninja构建脚本。当我们运行 make 或 ninja 时，这些构建工具会检查每个目标文件（比如 main.o）和它的源文件（比如 main.c）之间的依赖关系。如果源文件的修改时间比目标文件更新，构建工具才会重新编译这个源文件，生成新的目标文件。在这个过程中，编译器才会去读取源文件的新修改时间，填入 __TIMESTAMP__。

所以，问题的核心就变成了：如何让构建系统“认为”我们的源文件发生了修改，从而触发重新编译？

如果你只是简单地重新运行 cmake --build .，但源文件内容本身和修改时间都没变，构建系统会聪明地跳过编译，直接链接已有的目标文件，这就是所谓的“增量编译”，是提升大型项目构建速度的关键。但这也导致了 __TIMESTAMP__ 不更新。

别担心，下面我就分享三种我实战中常用的、能稳定“骗过”CMake和构建系统，强制重新编译特定文件的方法。每种方法都有其适用场景和细微的坑，我会结合具体例子，带你一步步搞定。

2. 方法一：创建“虚拟依赖”文件

这是最经典、也最直观的一种思路。既然构建系统只认文件的修改时间，那我们就人为地创建一个每次构建都会更新的“触发器”文件，然后让我们需要更新时间的源文件依赖于这个触发器。

2.1 核心原理与操作步骤

这个方法的精髓在于 add_custom_command 和 add_custom_target 的配合使用。我们创建一个每次构建都会重新生成的、内容为当前时间的头文件（例如 timestamp.h），然后在我们的C源文件中包含这个头文件。由于头文件每次都是新的，依赖它的源文件也就必须重新编译。

具体CMakeLists.txt的配置如下：

# 定义一个生成时间戳头文件的命令
add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/generated/timestamp.h  # 指定输出文件路径
  COMMAND ${CMAKE_COMMAND} -E echo \"#define COMPILE_TIMESTAMP \\\"$ENV{COMPILE_TIME}\\\"\" > ${CMAKE_BINARY_DIR}/generated/timestamp.h
  COMMENT \"正在生成编译时间戳头文件\"
  VERBATIM
)

# 创建一个始终会执行上述命令的目标
add_custom_target(
  generate_timestamp ALL
  DEPENDS ${CMAKE_BINARY_DIR}/generated/timestamp.h
)

# 将生成的头文件路径加入头文件搜索目录
target_include_directories(your_target_name PRIVATE ${CMAKE_BINARY_DIR}/generated)

# 让我们主构建目标依赖于时间戳生成目标
add_dependencies(your_target_name generate_timestamp)

这里有几个关键点需要注意。首先，我习惯把生成的文件放在 ${CMAKE_BINARY_DIR}/generated 目录下，这样能清晰地区分源代码和构建时生成的文件，避免污染源码树。其次，add_custom_target 命令加上了 ALL 参数，这意味着无论你指定构建哪个目标，generate_timestamp 这个目标都会被构建，确保时间戳文件总是被生成。

在C源文件中，你需要包含这个生成的头文件：

#include “generated/timestamp.h”

void print_build_time() {
    // 直接使用宏
    printf(“本程序编译于：%s\\n“, COMPILE_TIMESTAMP);
    // 同时，_