一、自定义命令与目标：让构建过程“活”起来

CMake 的构建系统，说白了就是一套“自动化流水线”。但很多时候，光靠内置的编译、链接指令根本不够用。比如你想在编译前自动生成代码，或者在链接后把产物打包成安装包——这时候，add_custom_command 和 add_custom_target 就派上用场了。

我个人习惯把这两个命令比作“瑞士军刀”。它们能让你在构建流程中插入任意脚本、调用外部工具，甚至定义全新的构建目标。嗯，咱们今天就把这把刀拆开看看。

1.1 add_custom_command：在构建流程中“插一脚”

这个命令的作用，是在某个特定时机执行一段自定义操作。它有两种常见用法：

• 文件生成型：当某个文件不存在或过期时，自动执行命令生成它。
• 目标后操作型：在某个目标（比如可执行文件）构建完成后，执行额外操作。

先看文件生成型的例子。假设你有一个 Python 脚本 gen_header.py，它会在编译前生成一个头文件 version.h：

add_custom_command(
    OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/version.h
    COMMAND python3 ${CMAKE_CURRENT_SOURCE_DIR}/gen_header.py
    DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/gen_header.py
    COMMENT "Generating version.h..."
)

这里的关键点是 OUTPUT 和 DEPENDS。CMake 会检查 version.h 是否存在，以及它的时间戳是否比依赖文件新。如果过期了，就重新执行命令。

再看目标后操作型。比如你想在链接完 myapp 后，自动运行一个测试脚本：

add_custom_command(
    TARGET myapp
    POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E echo "Build finished!"
    COMMAND python3 run_tests.py
    COMMENT "Running post-build tests..."
)

POST_BUILD 表示在目标构建完成后执行。还有 PRE_BUILD（构建前）和 PRE_LINK（链接前）两种时机，不过 PRE_BUILD 在有些生成器上行为不太一致，我建议优先用 POST_BUILD 或 PRE_LINK。

1.2 add_custom_target：定义你自己的构建目标

有时候，你需要一个“虚拟”的目标——它不编译任何代码，只是执行一组命令。比如你想定义一个 clean_all 目标，删除所有生成的文件：

add_custom_target(clean_all
    COMMAND ${CMAKE_COMMAND} -E remove_directory ${CMAKE_CURRENT_BINARY_DIR}/output
    COMMAND ${CMAKE_COMMAND} -E echo "Cleaned output directory."
)

运行 make clean_all 或 cmake --build . --target clean_all 就能触发。

自定义目标默认不会自动执行，除非你把它添加到 ALL 选项中：

add_custom_target(run_tests ALL
    COMMAND python3 run_all_tests.py
    COMMENT "Running all tests..."
)

这样每次构建时，run_tests 都会被执行。不过要小心——如果测试很慢，这会拖慢整个构建过程。

你还可以让自定义目标依赖其他目标。比如你想先编译 myapp，再运行测试：

add_custom_target(test_myapp
    COMMAND python3 run_tests.py
    DEPENDS myapp
)

这样 make test_myapp 会先确保 myapp 是最新的，再执行测试命令。

1.3 构建后操作：自动化收尾工作

构建后操作，说白了就是“编译完了，然后呢？”常见的场景包括：

• 把可执行文件复制到安装目录
• 生成文档或 API 参考
• 打包成压缩包或安装程序
• 发送通知（比如 Slack 消息）

我个人最常用的模式是结合 add_custom_command 的 POST_BUILD 和 install() 指令。比如：

add_executable(myapp main.cpp)

add_custom_command(TARGET myapp POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E copy
        $<TARGET_FILE:myapp>
        ${CMAKE_CURRENT_BINARY_DIR}/deploy/
    COMMENT "Copying myapp to deploy directory..."
)

install(TARGETS myapp DESTINATION bin)

这里用了生成器表达式 $<TARGET_FILE:myapp>，它能自动解析出目标文件的完整路径。嗯，生成器表达式是个好东西，后面章节会细讲。

1.4 知识体系图：自定义命令与目标的关系

下面这张图展示了 add_custom_command 和 add_custom_target 在构建流程中的位置，以及它们如何与其他 CMake 指令配合：

1.5 实战避坑指南

我在项目中遇到过不少自定义命令的“翻车”现场，这里列几个最常见的：

• 命令找不到：比如 python3 在 Windows 上可能是 python。我建议用 find_program() 先找到可执行文件路径，再传给 COMMAND。
• 依赖没写全：如果生成的文件依赖某个输入文件，一定要写在 DEPENDS 里。否则改了输入文件，CMake 不会重新生成。
• 跨平台路径问题：Windows 用反斜杠，Linux 用正斜杠。用 ${CMAKE_COMMAND} -E copy 代替直接调用 cp 或 copy，CMake 会帮你处理。
• 并行构建冲突：多个自定义命令同时写同一个文件？那会出大问题。确保每个 OUTPUT 是唯一的。

好了，自定义命令和自定义目标的核心内容就这些。它们就像构建系统的“胶水”，能把各种零散的操作粘合成一个流畅的自动化流程。下次你需要在构建过程中做点“额外的事”，记得回来翻翻这章。

---