咨询GNU Makefile解析执行的精确流程及规则合并逻辑

核心问题：同一目标的多规则合并逻辑 #

当你为同一个目标定义多条规则时，GNU Make在解析阶段会自动合并所有规则的前置条件，形成一个完整的依赖列表——不管这个前置条件是文件目标还是.PHONY目标，都会被无条件加入到目标的依赖集合中。这是Make处理多规则目标的核心行为，直接决定了后续自动变量的展开结果。

你的示例分析 #

先看你写的Make规则：

$(BUILD)/$(APP_NAME): $(OBJ_LIST)
    $(FP_COMPILER) $(PARAMS) $^ $(LPARAMS) -o $(BUILD)/$(APP_NAME)

$(BUILD)/$(APP_NAME): foo

foo:
    @echo bar

Make解析后，$(BUILD)/$(APP_NAME)的最终依赖列表是$(OBJ_LIST) + foo。而自动变量$^的定义就是目标的所有前置条件（去重后的完整列表），所以哪怕你把foo标记为.PHONY，它依然会被包含在$^的展开结果里，导致链接命令把foo当成输入文件，触发找不到文件的错误。

你遇到的错误输出也验证了这一点：

C:/msys64/mingw64/bin/g++.exe -Wall -g3 build/obj/main.o build/obj/phase1.o build/obj/phase2.o build/obj/phase3.o build/obj/helper/line_fetcher.o foo -lstdc++ -lm  -o build/test.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find foo: No such file or directory
collect2.exe: error: ld returned 1 exit status

Make内部逻辑的关键细节 #

1. 解析阶段 vs 执行阶段：
   • 解析阶段：Make先扫描所有Makefile，完成变量展开、规则合并（依赖列表合并，命令按顺序保留），这一步在任何命令执行前完成。
   • 执行阶段：根据解析后的依赖关系决定执行顺序，此时自动变量（如$^）才会展开，取值完全基于解析阶段合并好的依赖列表。
2. .PHONY的真实作用：
   .PHONY仅告诉Make「这个目标不是文件，每次都要执行它的命令」，不会改变它作为前置条件被加入目标依赖列表的行为，也不会让$^这类自动变量忽略它。

实现「前置操作但不被$^包含」的正确方式 #

如果需要某个操作在链接前执行，但不把它的目标加入$^，有两种可靠方式：

1. 使用顺序依赖（Order-Only Prerequisites）：
   Make支持用|分隔常规依赖和顺序依赖，顺序依赖只会影响执行顺序，不会被$^、$+等自动变量包含。修改后的规则：

   $(BUILD)/$(APP_NAME): $(OBJ_LIST) | foo
       $(FP_COMPILER) $(PARAMS) $^ $(LPARAMS) -o $(BUILD)/$(APP_NAME)
   
   foo:
       @echo bar
   

   这样foo会在链接命令执行前被执行，但$^只会展开$(OBJ_LIST)的内容。
2. 将操作直接写入链接命令：
   如果操作逻辑简单，可以直接把它放到链接规则的命令序列里：

   $(BUILD)/$(APP_NAME): $(OBJ_LIST)
       @echo bar
       $(FP_COMPILER) $(PARAMS) $^ $(LPARAMS) -o $(BUILD)/$(APP_NAME)
   

   这种方式不需要单独定义foo目标，直接在链接命令前执行前置操作。

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