何时应使用CMake的add_dependencies而非target_link_libraries？

先把核心区别说透：

• target_link_libraries()是链接导向的依赖：它不仅会保证依赖目标先于当前目标构建，还会处理所有链接相关操作——比如把依赖库的路径、头文件目录、编译选项传递给当前目标，最终让链接器把依赖库和当前目标整合起来。
• add_dependencies()是构建顺序导向的依赖：它只管“先构建谁，后构建谁”，完全不涉及链接操作，不会传递任何链接相关参数。

什么时候用target_link_libraries()？ #

只要你的当前目标需要链接某个库（静态库、动态库、OBJECT库、INTERFACE库等），就用它。比如：

• 写了个可执行文件，要链接自己项目里的静态库libfoo.a：

  add_executable(my_app main.cpp)
  target_link_libraries(my_app PRIVATE foo)
  

• 要链接第三方库（比如Boost、Qt的模块），也用它，CMake会自动处理链接路径和头文件。

这种场景下，target_link_libraries()已经帮你搞定了构建顺序（必须先建foo库才能链接到my_app），完全不需要额外加add_dependencies()。

什么时候必须用add_dependencies()？ #

当你需要保证某个目标先构建，但不需要链接它的时候，这就是add_dependencies()的主场：

场景1：依赖自定义生成目标 #

比如你用add_custom_target()写了个生成代码/配置文件的目标，主目标需要用到生成的文件，但不需要链接任何库。比如：

# 自定义目标：用脚本生成config.h
add_custom_target(gen_config
  COMMAND python3 generate_config.py ${CMAKE_BINARY_DIR}/config.h
)

# 可执行文件需要用到生成的config.h，但不需要链接gen_config（它不是库）
add_executable(my_app main.cpp)
# 确保gen_config先运行，生成config.h后再编译my_app
add_dependencies(my_app gen_config)

场景2：两个可执行文件之间的依赖 #

比如你有个工具可执行文件data_generator，它会生成数据文件input.dat，另一个可执行文件data_processor需要读取这个文件才能运行，但data_processor不需要链接data_generator的代码。这时候就需要用add_dependencies()保证data_generator先编译完成：

add_executable(data_generator generator.cpp)
add_executable(data_processor processor.cpp)

# 保证data_generator先构建好，运行data_processor时才有input.dat可用
add_dependencies(data_processor data_generator)

场景3：依赖非库类型的目标 #

比如你有个add_custom_command()生成的目标，或者一些只做构建前置操作的目标，这些目标本身没有库文件可以链接，只是需要在当前目标构建前完成，这时候只能用add_dependencies()。

关键提醒 #

绝对不要同时给同一个依赖用这两个命令！因为target_link_libraries()已经隐含了构建依赖，重复添加会让CMake的依赖解析逻辑混乱，可能导致构建顺序异常或者冗余操作。

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