6、Makefile条件判断：ifeq/ifneq/ifdef/ifndef、条件判断实战、多目标编译

条件判断，说白了就是让Makefile学会「看人下菜碟」。

我刚开始用Makefile那会儿，总觉得这东西就是个自动化脚本，写死就完了。直到有一次接手一个跨平台项目——同一套代码要在Linux、ARM嵌入式板子和一个老旧的uClinux上编译。每个平台的编译器路径、链接参数、甚至源文件列表都不一样。如果写三个Makefile，维护起来简直是噩梦。

嗯，条件判断就是解决这个问题的。

6.1 条件判断的基本语法

Makefile的条件判断不像C语言那样用if-else花括号。它用的是指令风格，有点像汇编里的条件汇编。核心就四个：ifeq、ifneq、ifdef、ifndef。

6.1.1 ifeq 和 ifneq

ifeq 判断两个值是否相等。格式如下：

ifeq ($(VARIABLE), value)
    # 相等时执行的语句
else
    # 不相等时执行的语句
endif

注意那个奇怪的括号和逗号写法。我刚开始写的时候老记混，后来总结了个规律：ifeq 后面跟一对括号，括号里用逗号分隔两个比较对象。你也可以写成：

ifeq "$(VARIABLE)" "value"

两种写法等价，我个人习惯用括号版本，看着更紧凑。

ifneq 正好反过来，判断两个值不相等时执行：

ifneq ($(CC), gcc)
    $(warning 当前编译器不是gcc)
endif

我曾经在一个项目里遇到过这样的坑：某个模块在ARM交叉编译时链接失败，查了半天发现是Makefile里用 ifeq ($(ARCH), arm) 判断架构，但变量 ARCH 的值是 armv7，不是精确的 arm。条件永远不成立，导致链接参数没加上。所以，比较时一定要确认变量值完全匹配。

6.1.2 ifdef 和 ifndef

这两个判断变量是否「被定义」。注意，不是判断值是否为空，而是判断变量有没有被定义过。

ifdef DEBUG
    CFLAGS += -g -O0
endif

如果 DEBUG 变量被定义了（哪怕定义成空值），这个条件就成立。你想想看，这跟判断值是否为空是有区别的：

# 情况1：变量被定义，值为空
DEBUG =
ifdef DEBUG
    # 这个分支会执行！
endif

# 情况2：变量未被定义
# 没有定义 DEBUG
ifdef DEBUG
    # 这个分支不会执行
endif

这个细节我栽过跟头。有一次我在命令行传了 make DEBUG=，以为没传值就等于没定义，结果条件判断通过了，编译出了带调试符号的版本，导致固件体积超标。嗯，这里要注意：ifdef 只看「有没有」，不看「是什么」。

6.2 条件判断实战：跨平台编译

光讲语法没意思，咱们来点实战。下面是我在一个嵌入式项目中用到的条件判断结构：

# 检测主机架构
HOST_ARCH := $(shell uname -m)

# 根据架构选择编译器
ifeq ($(HOST_ARCH), x86_64)
    CC := gcc
    CFLAGS += -m64
else ifeq ($(HOST_ARCH), aarch64)
    CC := aarch64-linux-gnu-gcc
    CFLAGS += -march=armv8-a
else ifeq ($(HOST_ARCH), armv7l)
    CC := arm-linux-gnueabihf-gcc
    CFLAGS += -march=armv7-a -mfpu=neon
else
    $(error 不支持的架构: $(HOST_ARCH))
endif

# 调试模式开关
ifdef DEBUG
    CFLAGS += -g -DDEBUG_ENABLED
    LDFLAGS += --no-gc-sections
else
    CFLAGS += -O2 -DNDEBUG
    LDFLAGS += --gc-sections
endif

这段代码里用了 ifeq-else ifeq-else-endif 的多分支结构。注意，Makefile 不支持 elseif 连写，必须写成 else ifeq 中间有空格。

我还喜欢用 ifdef 做功能开关：

# 功能模块开关
ifdef ENABLE_USB
    SRC_C += usb_driver.c
    CFLAGS += -DHAVE_USB
endif

ifdef ENABLE_WIFI
    SRC_C += wifi_driver.c
    CFLAGS += -DHAVE_WIFI
endif

这样在编译时，通过命令行传参就能灵活裁剪功能：

make ENABLE_USB=1 ENABLE_WIFI=1

6.3 多目标编译

一个Makefile编译多个目标，这在实际项目中太常见了。比如一个项目里既有bootloader、又有kernel、还有应用程序。每个目标的编译参数、源文件、链接脚本都不一样。

我常用的做法是用条件判断配合伪目标：

# 定义三个目标
TARGETS := bootloader kernel app

# 默认目标
all: $(TARGETS)

# 通用编译规则
%.o: %.c
    $(CC) $(CFLAGS) -c $< -o $@

# bootloader 编译
bootloader: CC := arm-none-eabi-gcc
bootloader: CFLAGS := -mcpu=cortex-m3 -mthumb -Os -ffreestanding
bootloader: LDFLAGS := -T bootloader.ld -nostdlib
bootloader: boot_start.o boot_main.o
    $(CC) $(LDFLAGS) $^ -o $@.elf

# kernel 编译
kernel: CC := arm-linux-gnueabi-gcc
kernel: CFLAGS := -march=armv7-a -O2 -fno-pic
kernel: LDFLAGS := -T kernel.ld -Map kernel.map
kernel: head.o main.o mm.o sched.o
    $(CC) $(LDFLAGS) $^ -o $@.elf

# app 编译
app: CC := arm-linux-gnueabi-gcc
app: CFLAGS := -O2 -Wall -fPIC
app: LDFLAGS := -shared -Wl,-soname,libapp.so
app: app_module1.o app_module2.o
    $(CC) $(LDFLAGS) $^ -o $@.so

这里有个技巧：我把目标名当作「命名空间」来用。每个目标前面加上目标名，后面跟变量赋值，这样变量作用域就限定在这个目标内部。比如 bootloader: CC := ... 只在编译 bootloader 时生效，不会影响 kernel 的编译器设置。

你可能会问：如果我想同时编译多个目标，但每个目标用不同的编译器怎么办？上面的写法已经解决了——每个目标独立设置自己的 CC、CFLAGS，互不干扰。

6.4 条件判断的嵌套与注意事项

条件判断可以嵌套，但我不建议嵌套超过两层。看个例子：

ifdef FEATURE_A
    ifeq ($(PLATFORM), linux)
        CFLAGS += -DFEATURE_A_LINUX
    else
        CFLAGS += -DFEATURE_A_GENERIC
    endif
endif

嵌套多了，Makefile的可读性会急剧下降。我个人的经验是：如果条件逻辑太复杂，不如拆成多个小Makefile，或者用shell脚本预处理一下。

6.5 知识体系图

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

从图中可以看到，四个条件指令是基础，它们支撑起跨平台编译和功能开关两大应用场景，最终落到多目标编译这个实战需求上。底部的注意事项是我在实际开发中踩过的坑，写出来提醒大家。

好了，条件判断这块就讲到这里。记住一个原则：条件判断是为了让Makefile更灵活，不是为了炫技。能用简单逻辑解决的，别搞复杂嵌套。代码是写给人看的，顺便让机器执行。