如何编写兼容GNU Make与BSD Make的多编译配置Makefile

方案1：递归Make调用（推荐） #

这种方式完全遵循POSIX标准，所有Make工具都支持，且天然避免并行编译时的变量冲突问题：

# 基础编译标志
BASE_FLAGS := -static -W -Wall -Wextra

# Debug 构建入口
debug:
	$(MAKE) FLAGS="$(BASE_FLAGS) -g -ggdb" build

# Release 构建入口
release:
	$(MAKE) FLAGS="$(BASE_FLAGS) -O2 -flto" build

# 实际构建规则（保留你原有的大量使用$(FLAGS)的逻辑）
build:
	# 示例编译命令，替换为你的实际规则
	# cc $(FLAGS) -o myapp src/*.c

原理说明：

• 执行make debug或make release时，会启动新的Make进程，将对应FLAGS作为参数传递，完全隔离不同构建模式的变量环境。
• 并行编译（make -j）不会出现变量竞争，因为debug/release的构建进程相互独立。
• 完全兼容GNU Make和BSD Make，符合POSIX Make规范。

方案2：基于MAKECMDGOALS的条件判断 #

如果不想用递归调用，也可以通过MAKECMDGOALS（GNU和BSD Make均支持该变量）提前设置FLAGS：

BASE_FLAGS := -static -W -Wall -Wextra

# 根据目标设置FLAGS
ifneq ($(filter debug,$(MAKECMDGOALS)),)
FLAGS := $(BASE_FLAGS) -g -ggdb
else ifneq ($(filter release,$(MAKECMDGOALS)),)
FLAGS := $(BASE_FLAGS) -O2 -flto
endif

# 入口目标依赖build
debug release: build

# 实际构建规则
build:
	# 示例编译命令
	# cc $(FLAGS) -o myapp src/*.c

注意事项：

• 该方式在Make解析阶段就确定FLAGS的值，避免运行时变量修改的冲突。
• 若同时执行make debug release，FLAGS会以最后匹配的目标为准（此处为release），但通常不会同时触发两种构建模式。

原方案的问题根源： #

• 使用eval在规则执行阶段修改全局FLAGS，并行编译时多个规则可能同时修改该变量，导致FLAGS值混乱。
• 仅GNU Make支持的|（顺序仅依赖）语法，BSD Make无法识别，引发兼容性问题。

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