CMake 中 add_definitions() 使用的注意事项及替代方案

在 CMake 中使用 add_definitions() 函数时，虽然其作用范围是全局的，但在实际应用中可能会遇到一些问题，导致其对子目录的影响不如预期。理解和避免这些问题可以帮助更高效地使用 CMake 管理项目构建。以下是一些可能影响 add_definitions() 效果的因素，以及如何解决这些问题的建议。

1. 子目录的处理顺序

确保在调用 add_subdirectory() 包含子目录之前使用 add_definitions()。这样可以确保定义传递给所有子目录中的目标。

正确的示例:

add_definitions(-DLINUX)
add_subdirectory(subdir)

错误的示例:

add_subdirectory(subdir)
add_definitions(-DLINUX)

在错误的示例中，subdir 目录中的目标不会接收到 -DLINUX 定义，因为它们已经在定义添加之前被处理。

2. 子目录中的重写

子目录中的 CMakeLists.txt 文件可能使用 remove_definitions() 或其他方法显式地修改或取消从父目录继承的定义。这可能导致预期之外的构建行为。

3. 缓存和变量作用域

如果使用变量来设置定义，并且这些变量在父目录中没有正确地传递到子目录（如未使用 CACHE 或 PARENT_SCOPE），那么子目录中的目标将不会受到这些定义的影响。

4. 命令调用位置

add_definitions() 必须在定义相关目标之前调用。如果在目标已经定义后才调用 add_definitions()，那么这些目标将不会包含新增的预处理器定义。

5. 使用建议的替代方案

为了精确控制定义的作用范围并避免潜在的全局污染，推荐使用 target_compile_definitions() 而非 add_definitions()。这样可以为特定目标直接设置编译定义。

add_executable(MyExecutable source.cpp)
target_compile_definitions(MyExecutable PRIVATE LINUX)

这种方法确保只有指定的目标受到定义的影响，提高了构建过程的清晰度和可控性。

通过上述措施，可以更有效地管理 CMake 项目中的编译定义，确保构建过程符合预期，同时提高项目的可维护性和可扩展性。