递归Makefile场景下预定义编译变量无法覆盖的解决方法

变量无法覆盖是两个配置错误叠加导致的：

• 你定义的递归make命令带了-e参数：_MAKE := $(MAKE) --no-print-directory -C $(_THIS) -e。-e参数会强制让环境变量优先级高于Makefile内的普通赋值，很容易打乱变量优先级逻辑。
• 你在便捷目标的递归命令里硬编码了PGO=1这类参数，按照GNU Make的规则，命令行传入的变量优先级是最高的，不管你在Makefile里用:=、=还是?=赋值，都没法覆盖命令行硬传的值，这是Make本身的设计，不是异常。

1. 移除_MAKE定义里的-e参数 #

把_MAKE改成：

_MAKE     := $(MAKE) --no-print-directory -C $(_THIS)

去掉-e之后，环境变量不会再随意覆盖Makefile内部的赋值，避免无意义的优先级冲突。

2. 给便捷目标的预设值加「未定义才赋值」的判断 #

不要在递归调用的命令行里写死参数值，先判断用户调用外层make时有没有手动传入对应变量，没传才加载你预设的默认配置，传了就优先用用户传入的值。
以native和pgo目标为例，改法如下：

native:
    $(eval DEBUG ?= 0)
    $(eval NATIVE ?= 1)
    $(eval PGO ?= 0)
    $(eval LTO ?= 1)
    $(eval DETECT ?= 1)
    $(_MAKE) build DEBUG=$(DEBUG) NATIVE=$(NATIVE) PGO=$(PGO) LTO=$(LTO) DETECT=$(DETECT) NAMING=$(NAMING) STATIC=$(STATIC) EXE_NAME=$(EXE_NAME)

pgo:
    $(eval DEBUG ?= 0)
    $(eval NATIVE ?= 1)
    $(eval PGO ?= 1)
    $(eval LTO ?= 1)
    $(eval DETECT ?= 1)
    $(_MAKE) build DEBUG=$(DEBUG) NATIVE=$(NATIVE) PGO=$(PGO) LTO=$(LTO) DETECT=$(DETECT) NAMING=$(NAMING) STATIC=$(STATIC) EXE_NAME=$(EXE_NAME)

这里用?=赋值符的作用是：变量已经有值（比如用户命令行传了、之前的逻辑已经赋值了）就不改动，没有值才设为后面的默认值。
改完之后的效果：

• 直接执行make pgo不传额外参数时，会自动加载PGO=1、LTO=1等预设的优化配置
• 执行make pgo PGO=0时，因为PGO已经被用户手动设为0，预设的PGO?=1不会生效，递归调用时会用用户传入的PGO=0
• 如果你需要在Makefile内部逻辑里调整变量值，只要调整动作在递归调用之前执行，就能正常生效，不会被硬编码的参数锁死。

补充说明 #

GNU Make的变量优先级从高到低是固定的：

• 命令行传入的变量
• 带override关键字的Makefile内部赋值
• Makefile内普通:=/=/?=赋值
• 系统环境变量（不带-e参数时优先级低于Makefile内部赋值）
• Makefile中定义的默认值

如果确实需要在Makefile内部强制覆盖命令行传入的变量，可以给赋值语句加override前缀，比如override PGO := 0就可以覆盖命令行传的PGO值，但这种写法会让用户手动传入的参数失效，便捷配置场景不建议使用，违背用户预期。

你现有的release目标也可以用同样的逻辑改造，支持用户临时覆盖STATIC、NAMING这类通用参数，不用每次修改目标里的硬编码值。

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