15. 定义与编译定义：target_compile_definitions、add_definitions、条件编译、平台相关定义

说到编译定义，这玩意儿在C/C++项目里太常见了。说白了，就是在编译时往代码里塞一些宏，让代码能根据不同的条件走不同的分支。我刚开始用CMake那会儿，觉得这功能不就是加个-D参数嘛，有啥好学的？后来项目一复杂，才发现这里面的门道还真不少。

15.1 两种定义方式：全局 vs 目标级

CMake提供了两种添加编译定义的方式，它们的作用范围完全不同。

15.1.1 add_definitions() —— 全局的“大喇叭”

add_definitions()是CMake早期就有的命令。它会往当前目录及所有子目录的所有目标中添加定义。用法很简单：

add_definitions(-DUSE_FEATURE_A -DDEBUG_LEVEL=2)

注意写法，要带上-D前缀，就像在命令行里一样。我个人习惯在非常小的项目或者快速原型里用这个，因为它够简单。但一旦项目超过两三个目标，我就不推荐了。

15.1.2 target_compile_definitions() —— 精准的“手术刀”

这才是现代CMake推荐的方式。它只影响指定的目标，不会波及无辜。语法如下：

target_compile_definitions(my_target
    PRIVATE
        MY_INTERNAL_FLAG=1
    PUBLIC
        MY_PUBLIC_FLAG
    INTERFACE
        MY_INTERFACE_FLAG
)

这里的关键是作用域关键字：

关键字	对当前目标	对链接当前目标的其他目标
PRIVATE	✅ 生效	❌ 不生效
PUBLIC	✅ 生效	✅ 生效
INTERFACE	❌ 不生效	✅ 生效

举个例子。假设你写了一个日志库，它内部用了一个LOG_INTERNAL_BUFFER_SIZE宏。这个宏是库的实现细节，对外部使用者毫无意义。那就用PRIVATE。如果这个库定义了一个LOG_VERSION宏，使用者需要知道版本号，那就用PUBLIC。

15.2 条件编译 —— 让代码“见风使舵”

条件编译是编译定义最常见的用途。代码里写#ifdef，CMake里控制这个宏是否定义。

15.2.1 基于构建类型

最常见的场景：Debug和Release用不同的宏。

target_compile_definitions(my_app PRIVATE
    $<$<CONFIG:Debug>:DEBUG_MODE>
    $<$<CONFIG:Release>:NDEBUG>
)

这里用了生成器表达式。$<$<CONFIG:Debug>:DEBUG_MODE>的意思是：如果当前构建类型是Debug，就定义DEBUG_MODE。嗯，这个语法看着有点怪，但用熟了就好。

15.2.2 基于平台

跨平台项目里，不同操作系统需要不同的宏。比如：

if(WIN32)
    target_compile_definitions(my_lib PRIVATE PLATFORM_WINDOWS)
elseif(APPLE)
    target_compile_definitions(my_lib PRIVATE PLATFORM_MACOS)
elseif(UNIX)
    target_compile_definitions(my_lib PRIVATE PLATFORM_LINUX)
endif()

代码里就可以这样用：

#ifdef PLATFORM_WINDOWS
    // Windows 特有的代码
    #include <windows.h>
#elif defined(PLATFORM_LINUX)
    // Linux 特有的代码
    #include <unistd.h>
#endif

15.3 平台相关定义 —— 那些“约定俗成”的宏

有些宏是编译器或平台自动定义的，你不需要手动添加。比如：

• _WIN32：Windows平台，MSVC或MinGW都会定义
• __linux__：Linux平台
• __APPLE__：macOS/iOS平台
• __ANDROID__：Android平台

但我不建议完全依赖这些编译器内置宏。为什么？因为可读性差。你写个#ifdef _WIN32，新人一看可能懵了：“这宏哪来的？” 更好的做法是在CMake里封装一层：

if(WIN32)
    target_compile_definitions(my_app PUBLIC IS_WINDOWS)
endif()

这样代码里就是#ifdef IS_WINDOWS，语义清晰多了。我曾经在一个项目里看到满屏的#ifdef __GNUC__、#ifdef _MSC_VER，维护起来那叫一个痛苦。后来我们统一在CMake里定义了COMPILER_GCC、COMPILER_MSVC这样的宏，世界清净了。

15.4 避坑指南

这里列几个我踩过的坑：

• 定义重复： 同一个宏被多次定义，编译器会警告。用add_definitions时特别容易发生。解决方案：用target_compile_definitions配合生成器表达式做精确控制。
• 忘记加值： target_compile_definitions(my_target PRIVATE MY_FLAG) 只是定义了宏，但没有值。代码里用#ifdef MY_FLAG没问题，但如果用#if MY_FLAG就会报错。需要赋值的话写成MY_FLAG=1。
• INTERFACE滥用： 把内部实现细节用INTERFACE传播出去，会导致所有依赖目标都被迫定义一堆无意义的宏。记住：INTERFACE只用于接口契约。

15.5 知识体系总览

下面这张图总结了本章的核心逻辑：

说白了，编译定义就是CMake和C/C++代码之间的“信使”。CMake负责在构建时决定“要传递什么信息”，代码负责在编译时“根据信息做决策”。把握好target_compile_definitions这个精准工具，你的项目就能在复杂环境中游刃有余。

---