1. 动手之前先搞懂makefile为什么值得写1.1 没有makefile时我在手工编译上吃过的亏说实话我刚接触Linux开发那会儿对makefile是有点不以为然的。那时候我手头就三五个源文件一条gcc命令能搞定的事绕来绕去写个makefile看起来完全是脱裤子放屁。真让我改变观念的是某次项目文件涨到十几个又加了几个目录级的头文件我每次改完代码都在终端里敲一长串编译命令敲错一个路径就要重新来。后来有一次我把一个头文件加了新的接口结果忘记把依赖它的所有.c文件重新编译链接出来的程序运行到一半直接段错误排查了两个小时最后才发现是一个旧的目标文件在作祟。从那之后我才真正理解makefile不是在帮你省那条编译命令而是在帮你管理什么变了、要重新编译什么、按什么顺序编译这套麻烦逻辑。尤其是在Linux下做C/C项目哪怕只是在自己的开发机里写个小工具用不了一个月你也会被手工编译搞得崩溃。等你转到嵌入式Linux开发面对交叉编译、多目录源码、外部头文件依赖的时候没有makefile几乎寸步难行。这篇内容我不打算给你贴那种满是伪代码的教程而是用我实际写过的项目来拆解makefile的整个编写过程从一行规则开始到最后能自动处理头文件依赖、支持增量编译、还方便切换交叉工具链的完整工程文件。适合那种刚刚从一条gcc到底的舒适区走出来开始认真对待工程化编译的读者也适合面试前临时抱佛脚把makefile的核心考点撸一遍的朋友。1.2 makefile到底帮你做了什么先回答一个很多人没真正理解的问题makefile和make是什么关系make是一个命令工具它按照你说的规则去执行编译、打包、清理makefile是你写给make看的一套剧本告诉它目标文件怎么生成、依赖哪些源文件、用什么命令去生成。本质上make做的是一件事根据依赖关系判断哪些目标需要重建然后按规则执行命令。这个判断哪些目标需要重建的能力是你手写编译命令永远得不到的。它的核心依据是时间戳如果依赖文件比目标文件更新make就认为目标过期了需要重新生成否则就跳过。这就是增量编译的基本原理。听起来很简单但正是这个机制让你的项目在几百个源文件规模下依旧可以几秒内完成构建而手工编译脚本一次就要全量重编。makefile的另一个隐性价值是约定。你写清楚了一套规则别人拿到源码后不需要问你怎么编译一个make命令就能出结果。这点在开源项目、团队协作里多重要我相信被同事拉着问我该先编译哪个文件的人都有体会。所以说makefile不只是给机器看的也是给下一个接手你代码的人看的。2. 编写第一个makefile前必须掌握的核心语法2.1 规则的三要素目标、依赖、命令makefile最基础的单元是规则长这样目标: 依赖文件列表 命令目标通常是你要生成的文件名比如可执行程序或者.o文件依赖文件列表是生成目标需要的东西可以是源文件也可以是其他目标命令就是真正干活的shell命令。这里有个无数新手踩过的坑命令行的开头必须是一个Tab键不能用空格代替。我在VSCode里写makefile时就经常因为编辑器把Tab自动转成4个空格然后make直接报错missing separator这种问题真能卡你十分钟。举个最小例子。假设我有个hello.c要生成hello这个可执行文件hello: hello.c gcc -o hello hello.c在终端里敲makemake会检查当前目录有没有hello文件没有就执行下面那条gcc命令如果hello已经存在再检查hello.c有没有比hello更新如果hello.c刚刚改过也会重新编译。这就是最原始的增量编译逻辑。依赖关系可以很长比如app: main.o util.o gcc -o app main.o util.o main.o: main.c util.h gcc -c main.c util.o: util.c util.h gcc -c util.c这种写法清晰但缺点是要重复写文件名和命令。等源文件一多你要维护的东西比手写编译命令还多那makefile就变成了另一个负担。所以我们需要变量、通配符和隐含规则来减负。2.2 变量、通配符与隐含规则变量的作用跟C语言里的宏类似可以让你把重复出现的编译器、选项、文件名统一收口。最常见的变量定义CC gcc CFLAGS -Wall -g -O2 TARGET app SRCS main.c util.c OBJS $(SRCS:.c.o)这里SRCS源文件列表OBJS利用替换引用写法把.c后缀换成.o等价于OBJS main.o util.o用变量之后规则可以写成$(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $(TARGET) $(OBJS)这样改编译器、加编译选项只需要动一行不用满文件找gcc。make还内置了隐含规则如果你在makefile里写了main.o: main.c这样的规则但忘了写命令make会用默认的编译命令去处理也就是$(CC) -c main.c -o main.o。但隐含规则有它自己的变量比如CC、CFLAGS如果你自定义了CC它也会用你定义的那个。这就是为什么很多人不写命令也能编出.o文件。自动变量是另一个提高效率的点常用三个$表示当前目标名$^表示所有依赖文件列表$表示依赖文件列表中的第一个例如main.o: main.c util.h $(CC) $(CFLAGS) -c $ -o $这样即使文件名变了规则也不用手改。但注意这里推荐写成$(CC) $(CFLAGS) -c $ -o $而不是gcc -c main.c这种硬编码因为一旦切交叉编译器你只需要改CC变量命令本身不动。3. 实战从一个干净目录开始编写可复用的makefile3.1 设计目录结构与源码拆分理论讲再多不动手都是空的我拿一个实际的工程结构来演示。假设我要写一个命令行小工具源码放在src目录头文件放在include目录构建产物放在build目录这算是我比较喜欢的基础布局project/ ├── include/ │ └── util.h ├── src/ │ ├── main.c │ └── util.c └── Makefileinclude里是util.h声明一个辅助函数src/main.c是入口src/util.c实现那个函数。这样代码量不大但能把makefile里的核心问题都串起来。先看一眼源文件长什么样。util.h#ifndef UTIL_H #define UTIL_H int add_one(int x); #endifutil.c#include util.h int add_one(int x) { return x 1; }main.c#include stdio.h #include util.h int main(void) { printf(%d\n, add_one(41)); return 0; }注意main.c里引入了util.h这意味着main.o依赖util.h。如果util.h被修改所有包含了它的源文件都应该重新编译。这个依赖关系正是makefile最难手工维护的地方。我先给出一个不用任何特殊手段的makefile版本CC gcc CFLAGS -Wall -Iinclude TARGET build/demo OBJS build/main.o build/util.o $(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $(TARGET) $(OBJS) build/main.o: src/main.c include/util.h $(CC) $(CFLAGS) -c src/main.c -o build/main.o build/util.o: src/util.c include/util.h $(CC) $(CFLAGS) -c src/util.c -o build/util.o clean: rm -f build/*.o $(TARGET)这里有几个细节要说一下。-Iinclude让编译器去include目录找头文件这样main.c里的stdio.h还是从系统头文件路径找而util.h会先找当前目录再去-I指定路径所以能找到include/util.h。3.2 头文件路径与自动依赖生成上面这个makefile能用但有一个明显的隐患我把依赖里的include/util.h写死了。如果哪天我在main.c里又多包含了一个config.h我必须在规则里加上它否则改config.h的时候make根本不知道要去重编main.o。等你项目里每个.c都包含四五个自定义头文件时维护这套依赖表绝对是一场灾难。真正的解决方案是利用编译器的自动依赖生成功能。GCC提供-MMD选项在编译的过程中顺带生成一个.d文件里面就是该源文件的实际头文件依赖列表。比如编译main.c时gcc会生成main.d内容大概长这样build/main.o: src/main.c include/util.h /usr/include/stdio.h ...把生成的依赖文件引用进makefilemake就自动知道main.o依赖哪些头文件了。做法也很简单SRCS src/main.c src/util.c OBJS $(SRCS:src/%.cbuild/%.o) DEPS $(OBJS:.o.d) $(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $(TARGET) $(OBJS) build/%.o: src/%.c include/%.h $(CC) $(CFLAGS) -MMD -c $ -o $ -include $(DEPS)这里用了一个模式规则build/%.o: src/%.c意思是任何build目录下的.o文件都从src目录下对应的.c文件生成。但依赖里还加了include/%.h这个其实有点投机取巧只对同名头文件有效。更严谨的做法是连include/%.h都不加单纯靠-MMD生成依赖build/%.o: src/%.c $(CC) $(CFLAGS) -MMD -c $ -o $虽然规则里没写头文件依赖但gcc生成的.d文件已经把真实的头文件依赖记录下来了-include $(DEPS)让make把所有.d文件当成makefile片段读进来。这样任何头文件变动make都能感知到。我用这个方案之后再没因为忘了写依赖导致过编译产物过期的问题。注意这里的DEPS变量在第一次编译前是不存在的因为还没有生成任何.d文件。用-include而不是include可以避免报错make会把缺失文件当作正常情况忽略。3.3 增量编译与Phony目标上面这个工程可以直接make了但我还得加一个clean目标用来清掉构建产物防止老文件污染新编译结果。这块在真实开发里绕不过去尤其是嵌入式开发换个工具链版本之后不清掉旧的.o文件经常编译出一堆诡异的链接错误。clean规则的写法有两种坑。第一个坑是你不能真建一个名叫clean的文件否则make认为clean已经存在且没有依赖永远不去执行它的命令。所以要用.PHONY声明一下.PHONY: all clean all: $(TARGET) clean: rm -f build/*.o build/*.d $(TARGET).PHONY: clean的意思是clean不是一个真正的文件目标只要执行make clean就无条件跑命令。同理all也是一个伪目标负责把真正的目标列在依赖里这样你在终端敲make和make all是一个效果。如果你把伪目标定义成普通目标某天手滑在项目目录里创建一个名叫clean的文件夹你的clean命令就再也不生效了这种问题我遇到过一次排查了半小时才回过神来。有了.PHONY和自动依赖这个makefile已经能达到改完代码按一下make不对的和依赖它的文件自动重编其余跳过的效果。此时你在终端里输入make能看到类似这样的输出cc -Wall -Iinclude -MMD -c src/main.c -o build/main.o cc -Wall -Iinclude -MMD -c src/util.c -o build/util.o cc -Wall -Iinclude -o build/demo build/main.o build/util.o第二次再敲make它只会显示make: build/demo is up to date.不会有任何编译动作。这就是时间戳机制生效的样子。4. 常见问题与排查技巧实录4.1 make没有指明目标并且找不到makefile到底怎么解这个报错基本上是从新手到老手都会撞见的因为它的诱发条件太多了但根因只有两个make没找到makefile或者找到了却不知道用什么目标。把这两个方向查清楚这个问题就能立刻定位。先看第一个方向。make默认在当前目录按顺序查找GNUmakefile、makefile、Makefile三个文件注意它查的是小写的makefile和大写的Makefile两种写法。如果你把文件命名为mk或者MakeFile这种变体make是找不到的。解决方案是启动时用-f显式指定文件名make -f mk build或者更常见的是你把makefile放在子目录里比如build/Makefile那你也得用-f或者-Cmake -C build-C会先切到build目录再执行make很多交叉编译脚本里就是这么调用的。再看第二个方向。假设makefile确实存在但make还是报没有指明目标那是因为makefile的第一个规则没有目标名或者第一个目标不是你期望的那个。一个常见的情况是用户把变量定义放到了第一行之后紧跟一个没有目标的规则片段比如CFLAGS -Wall echo hello这种语法可能让make理解成一个目标为空的规则执行的时候自然会报没有目标。再比如你写了一堆模式规则但没有一个具体目标make同样不知道你要什么。所以最基本的原则让第一个完整规则的第一个目标成为你默认执行的目标或者用all作为第一个目标把真正的目标挂上去。4.2 头文件改动后没有重新编译怎么办这个问题我在1.1里提过手工编译时代因为它吃了大亏。做了自动依赖之后理论上不会发生但实际里还是偶尔冒出来原因多半是依赖文件没有重新生成。比如你clone了一个别人的项目他的makefile没做-MMD只把头文件写死在某条规则里漏了一个路径。这种时候你改了头文件make不会去重编任何.o最后链接出来的程序还是旧逻辑。排查方法很直接在终端里执行make -d让make把整个决策过程打印出来它会显示Considering target file和Prerequisite ... is newer than target之类的信息一目了然。嫌输出太多就重定向到文件然后搜具体目标make -d make.log 21 grep main.o make.log如果你发现make根本没比较某个头文件的时间戳那基本可以确定是该头文件没被写进依赖表检查规则里的依赖列表和.d文件是否正常。还有一个隐蔽情况你自己手动把系统时间改乱过导致源文件时间戳早于.o文件make会认为不需要重建。修复手段很简单touch *.c把所有源文件时间改成当前时间或者直接clean重编。4.3 移植到RV1106这类嵌入式平台时的注意事项热词里出现了rv1106这是个典型的嵌入式Linux芯片我用类似的平台做过项目踩过一些和makefile相关的坑。嵌入式Linux和PC上搞开发基本的makefile逻辑都是通的但那几个差异点会坑死人。第一是交叉编译器。你的CC不再是gcc而是类似arm-rockchip-linux-gnueabihf-gcc这样的交叉编译工具定义在makefile的CC变量里。头文件路径也变了系统头文件不再是/usr/include而是交叉编译器自带的sysroot里的include目录比如-I$(SDKTARGETSYSROOT)/usr/include。如果你还写死gcc和/usr/include编译出来的程序在目标板上大概率跑不通。第二是库依赖。PC上你链接一个-lm就直接能从系统库里找到libm.so但嵌入式里你得给链接器额外指定-L$(SDKTARGETSYSROOT)/usr/lib甚至还要处理arm和thumb指令集下不同的库路径。我一般会把这类配置单独抽取到一个文件里比如config.mkMakefile里统一include config.mk这样换板子只需要改一个文件。第三是程序体积和编译选项。嵌入式Flash空间有限我在Makefile里常用-Os代替-O2再配合-fno-unwind-tables、-fno-asynchronous-unwind-tables这类裁剪选项减小最后的可执行文件。这些选项写在CFLAGS里改起来也很方便。下面是给嵌入式用的实际片段CROSS_COMPILE ? arm-rockchip-linux-gnueabihf- CC : $(CROSS_COMPILE)gcc CFLAGS : -Os -Wall -Iinclude -MMD LDFLAGS : -L$(SDKTARGETSYSROOT)/usr/lib这里用了?作用是如果外部环境已经传过CROSS_COMPILE就直接沿用否则用默认值。这样你在命令行可以临时覆盖make CROSS_COMPILEaarch64-linux-gnu-同一套makefile就能在x86和不同ARM平台之间切换实用性拉满。5. 几个让我少走弯路的makefile进阶技巧5.1 使用函数与条件判断实现多目标工程当项目从单可执行文件变成多可执行文件或者同一套源码要针对不同配置构建时makefile就得引入更高级的语法。我实际用比较多的是函数和条件判断。wildcard函数用于收集目录下所有匹配的文件SRCS : $(wildcard src/*.c)这样就可以自动把所有src目录下的.c文件加入编译列表新增文件不用改makefile。配patsubst转换成目标文件列表OBJS : $(patsubst src/%.c, build/%.o, $(SRCS))和之前用替换引用$(SRCS:.c.o)的效果类似但patsubst可以对路径前缀做更灵活的替换更清晰。条件判断适合处理调试版和发布版的差异ifeq ($(DEBUG), 1) CFLAGS -g -DDEBUG else CFLAGS -O2 endif终端里执行make DEBUG1就能编出带调试信息的版本。我在调试一个和浮点运算相关的bug时就是因为需要在不同优化级别下对比行为用这种方式切换特别方便。还有foreach函数在管理多个子目录时很有用。假设我有三个子目录core、net、app每个目录都要生成独立的静态库可以在makefile里循环处理SUBDIRS : core net app LIB_TARGETS : $(foreach dir, $(SUBDIRS), $(dir)/lib$(dir).a)然后配合模式规则逐个子目录构建。这种玩法在大型项目里很常见虽然也可以拆成多个子makefile用$(MAKE) -C逐级进入但有时候单文件里用foreach反倒更直观。5.2 实用模板示例可抄作业文章最后我放一个我目前经常用的makefile模板它集成了自动依赖、多目录、伪目标、变量覆盖这些功能你直接拿去改改路径就能用TARGET : demo CC ? gcc BUILD_DIR : build SRC_DIR : src INC_DIR : include CFLAGS : -Wall -O2 -I$(INC_DIR) -MMD LDFLAGS : SRCS : $(wildcard $(SRC_DIR)/*.c) OBJS : $(patsubst $(SRC_DIR)/%.c, $(BUILD_DIR)/%.o, $(SRCS)) DEPS : $(OBJS:.o.d) .PHONY: all clean all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $ $^ $(LDFLAGS) $(BUILD_DIR)/%.o: $(SRC_DIR)/%.c | $(BUILD_DIR) $(CC) $(CFLAGS) -c $ -o $ $(BUILD_DIR): mkdir -p $(BUILD_DIR) clean: rm -rf $(BUILD_DIR) $(TARGET) -include $(DEPS)简单解释几个设计点。第一$(BUILD_DIR)/%.o这个规则用了一个order-only前置依赖| $(BUILD_DIR)意思是如果build目录不存在就先去创建它但目录变化不会触发重新编译。第二-include $(DEPS)让第一次编译前不存在的.d文件被安全忽略。第三只定义了all和clean两个伪目标普通用户接触makefile只需要记make和make clean不会误触其他规则。我把这个模板直接用来做本地小项目和嵌入式板端应用唯一要改的也就是CC、CFLAGS、LDFLAGS那几行。当然如果你项目里需要多个可执行文件可以把每个文件的构建写成独立目标或者引入子目录mk文件那是另一个复杂度级别的玩法。最后分享一个小技巧写makefile的时候别急着追求一句规则走天下的炫技先把最简单的版本跑通再用-MMD补依赖最后再考虑函数和条件分支。我在实际项目里的体会是makefile最大的敌人不是语法复杂而是你用的规则太隐晦三个月后自己回头看都猜不出当初想干什么。所以命名要清晰、变量要有注释、尽量用通用的自动变量和模式规则这才是long-term真正省心的路。