很多朋友在Linux下写C/C代码时都有过这样的经历编译一个小项目在终端里一条条敲gcc命令文件少还好说文件一多或者换台机器重新编译就变成一场灾难。这时候Makefile就是那个能让你从重复劳动里解脱出来的东西。简单说Makefile就是一套编译脚本加依赖规则的组合你只需要敲一个make它就能按你定的规则完成编译、清理、安装等所有操作。这篇文章我会用一个完整的小项目手把手讲解Makefile的常用写法、变量与函数、多目录组织方式以及我在实际开发中踩过的坑适合刚接触Linux开发、想搞清楚make怎么用的读者。1. Makefile到底在解决什么问题1.1 从最原始的编译方式说起先还原一个真实场景。假设你要写一个简单的计算器程序代码拆成了下面这些文件main.c程序入口负责接收用户输入add.c/sub.c/mul.c/div.c四个运算模块calc.h公共头文件声明函数接口没有Makefile的时候你大概会这样编译gcc -c main.c -o main.o gcc -c add.c -o add.o gcc -c sub.c -o sub.o gcc -c mul.c -o mul.o gcc -c div.c -o div.o gcc main.o add.o sub.o mul.o div.o -o calc这个流程第一次跑没问题但第二次、第三次呢你改了一个add.c然后又要从头把五个文件全部编译一遍。如果工程里有几十上百个源文件这个重复编译的时间会让人非常崩溃。更麻烦的是你很难记住main.o到底依赖哪些头文件头文件更新了但对应的.o没重新编译最后链接出来的程序行为莫名其妙。Makefile解决的就是这两个核心问题一是把编译命令固化成一个可复用的流程二是在文件依赖关系的基础上实现增量编译——只重新编译那些真正发生了变化的源文件其余文件直接复用旧的.o文件。这第二点才是Makefile最值钱的地方它背后靠的是文件时间戳比较如果目标文件.o比依赖文件.c还要新说明源文件没改过这个目标就不需要重新构建。1.2 目标、依赖和规则的三角关系Makefile最基本的语法单元是“规则”结构是这样目标: 依赖 命令这里的“目标”通常是你想生成的文件比如main.o“依赖”是生成这个目标需要的东西比如main.c和calc.h而“命令”就是你实际要执行的动作比如gcc -c main.c。一个最容易忽略的细节是命令前必须是一个Tab字符不能是空格。我见过太多新手在这个地方栽跟头报错信息通常是missing separator。如果你用vscode或vim编辑Makefile建议把“显示不可见字符”打开确保缩进处是一个实实在在的Tab。Make的完整执行逻辑可以理解为三句话如果没有给make指定目标它就去找文件里第一条规则的目标来执行每个目标的依赖如果也是其他规则的目标就先递归构建那些依赖如果依赖文件比目标文件的时间戳还新就重新执行命令来更新目标这套机制看着简单但衍生出的变量、函数和自动化变量能让你的Makefile写得非常优雅。2. 从零手写一个Makefile单文件到多文件的完整演进2.1 单文件场景最小可用的Makefile我们先从最朴素的需求入手。只有一个hello.c编译成hello这个可执行文件。最直白的Makefile长这样hello: hello.c gcc hello.c -o hello clean: rm -f hello这里其实藏了一条Makefile的隐含规则。因为hello.c是存在的即使你不写依赖也能通过隐式规则编译出hello但那样做可读性太差也不利于后面的改造。上面的写法里一共有两条规则第一条目标是hello依赖hello.c第二条目标是clean没有依赖只负责清理文件。在终端执行makemake发现第一条目标是hello检查依赖hello.c存在且hello文件不存在或者比hello.c旧于是执行命令生成hello。再执行一次make它会提示“make: hello is up to date.”说明什么也不用做。这里就要引出一个概念如果clean这种目标并不真正生成一个文件而是执行一段动作那么它应该被声明为“伪目标”。否则如果当前目录下恰好存在一个名为clean的文件make会认为“clean”这个目标已经是最新的直接跳过执行rm命令就不会运行。解决办法是加上一句.PHONY: clean这样make就不会去检查有没有同名文件了。clean、all、install这类命令型目标最好都声明成.PHONY。2.2 多文件场景逐个写出所有规则回到计算器项目先写一个“老实人版本”的Makefilecalc: main.o add.o sub.o mul.o div.o gcc main.o add.o sub.o mul.o div.o -o calc main.o: main.c calc.h gcc -c main.c -o main.o add.o: add.c calc.h gcc -c add.c -o add.o sub.o: sub.c calc.h gcc -c sub.c -o sub.o mul.o: mul.c calc.h gcc -c mul.c -o mul.o div.o: div.c calc.h gcc -c div.c -o div.o clean: rm -f *.o calc .PHONY: clean这个写法能跑但问题也很明显每增加一个源文件就要多写两行如果改了编译器选项所有规则都要跟着改五条编译规则几乎一模一样唯一的区别就是文件名。这其实就是Makefile中“重复代码”的坏味道下一步必须引入变量和自动变量来消除。2.3 用变量和自动变量简化规则自动变量是make的内置变量只能在规则的命令部分使用。常用的三个是$代表当前规则的目标名$^代表所有依赖文件列表以空格分隔$代表依赖列表中的第一个依赖有了它们上面的编译规则就可以压缩成CC gcc CFLAGS -Wall -g calc: main.o add.o sub.o mul.o div.o $(CC) $^ -o $ %.o: %.c calc.h $(CC) $(CFLAGS) -c $ -o $ clean: rm -f *.o calc .PHONY: clean这里还用了一个“模式规则”%.o: %.c它表示“所有的.o文件都依赖同名的.c文件”。make遇到main.o这个目标时自动套用这条规则$就是main.c$就是main.o。这样不管以后加多少个源文件只要它们都依赖calc.h编译规则就不用再动。我第一次体会到自动变量的威力时真是有种写代码时的通透感。写Makefile和写程序是一样的事别重复自己。你越是把规则抽象出来后面改起来就越轻松。3. 进阶技巧变量、函数和模式规则组合起来用3.1 Makefile变量相当于代码里的常量Makefile里的变量非常简单用、:、?或来赋值。几种赋值方式看着相似实际意义不一样我建议一开始就搞清楚不然会碰到奇怪的问题。是递归展开赋值变量在真正使用的时候才展开。如果变量之间互相引用很容易出现无限递归或者取值不符合预期:是简单赋值在赋值时就立即展开右边的变量?是如果没有被赋值过才赋值适合给一些可覆盖的默认参数是追加赋值举一个区别的例子A 1 B $(A) A 2 C : 1 D : $(C) C : 2最终B的值是2因为B $(A)在取值时才去展开A而D的值是1因为在D : $(C)那一刻C已经被定死了。实际开发中我首选:避免后续变量被意外修改导致结果不可预测。常见变量的命名习惯如下CC : gcc CFLAGS : -Wall -Wextra -O2 -g LDFLAGS : -lm TARGET : calc SRCS : main.c add.c sub.c mul.c div.c OBJS : $(SRCS:.c.o)最后一行$(SRCS:.c.o)是变量替换引用把SRCS里所有.c后缀替换成.o等价于main.o add.o sub.o mul.o div.o。这个技巧可以避免你同时维护两份文件列表。3.2 常用函数wildcard、patsubst和foreach真正让Makefile变得灵活的是内建函数。先说最常用的wildcardSRCS : $(wildcard *.c)这行代码的意思是把当前目录下所有.c文件扩展成一个以空格分隔的列表。有了它你新增源文件后Makefile一行都不用改。配合patsubst可以做后缀替换OBJS : $(patsubst %.c, %.o, $(SRCS))这个写法和上面的$(SRCS:.c.o)效果一样但patsubst支持更复杂的模式比如匹配路径前缀。我曾经在把源码从src/目录重构到src/foo/目录的时候靠patsubst只改了一行就搞定了所有目标文件路径免去了逐个修改的麻烦。foreach函数则适合生成循环结构。比如你有几个子目录想要拼接出每个目录下所有.o文件的路径可以这样写SUBDIRS : src test tools OBJS : $(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.c))含义是对SUBDIRS中的每个目录名执行$(wildcard 目录/*.c)把所有结果拼在一起。这三个函数是Makefile里出现频率最高的熟练之后别说是单目录项目就是中型多目录项目也能用一份Makefile轻松管住。3.3 模式规则与内置隐含规则模式规则的核心就是一个带%的通配规则。前面写的%.o: %.c就是最典型的例子。它比写死每一条规则要灵活得多你甚至可以针对某一类文件专门定制编译参数# 普通源文件 %.o: %.c $(CC) $(CFLAGS) -c $ -o $ # 生成汇编文件 %.s: %.c $(CC) -S $(CFLAGS) $ -o $make本身还自带一堆隐含规则比如它知道.c文件可以编译成.o.o文件可以链接成可执行文件。如果你在规则里省略了命令部分make就会尝试用内置规则补齐。某些场景下这能节省不少代码量但也会带来“为什么它用的编译参数和我不一样”的困惑。我的建议是重要项目的编译命令要显式写清楚不要依赖隐含规则否则项目的可移植性会打折扣。4. 多目录工程怎样组织Makefile4.1 单Makefile方案一条规则通吃全部目录当项目结构变成这样时很多人会下意识地觉得需要每个子目录都放一个Makefile其实不一定project/ ├── Makefile ├── src/ │ ├── main.c │ └── calc/ │ ├── add.c │ ├── sub.c │ └── calc.h └── test/ └── test_main.c一个办法是用wildcard递归收集源文件再用patsubst批量生成目标文件最后通过VPATH或者直接带上目录前缀来访问头文件。一个比较简洁的写法是CC : gcc CFLAGS : -Wall -g -I./src/calc TARGET : calc SRCS : $(wildcard src/*.c src/calc/*.c test/*.c) OBJS : $(patsubst %.c, %.o, $(SRCS)) $(TARGET): $(OBJS) $(CC) $^ -o $ %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -rf $(OBJS) $(TARGET)这里-I./src/calc的作用是告诉编译器去src/calc目录下找头文件。%.o: %.c配合带目录的源文件路径生成的OBJS会是src/main.o、src/calc/add.o这样带路径的名字make会为每条规则先检查目录是否存在如果目录不存在就会报错。所以你需要确保这些中间目录是存在的一般源码都在不会有大问题。单Makefile方案的优点是逻辑集中全局依赖关系清晰调试相对容易缺点是工程一旦膨胀到几十个子目录这一个文件会很臃肿而且每次编译都要递归扫描所有目录效率会下降。4.2 递归Makefile方案子目录各自为政另一种常见做法是每个子目录一个Makefile再由顶层Makefile分发调用。每个子目录的Makefile只负责构建自己的目标通常长这样# src/calc/Makefile OBJS : add.o sub.o all: $(OBJS) %.o: %.c calc.h $(CC) $(CFLAGS) -c $ -o $顶层Makefile则遍历子目录SUBDIRS : src src/calc test all: for dir in $(SUBDIRS); do \ $(MAKE) -C $$dir; \ done clean: for dir in $(SUBDIRS); do \ $(MAKE) -C $$dir clean; \ done$(MAKE)是make的专有变量永远指向当前正在执行的make程序。这里必须用$(MAKE)而不是直接写make因为在并行编译make -j或者make被重命名时直接写make会出问题。递归Makefile的优点是把复杂的子任务拆开了每个目录可以有自己的编译参数、自己的清理逻辑缺点是依赖关系的管理比较麻烦如果你在顶层想判断某个子目录的东西是不是最新的就得一层层往下问构建速度反而可能变慢。很多大型项目就是用递归Makefile玩出花的。我的建议是如果你的工程在5个目录以内而且大家共享同一套头文件和编译选项优先用单Makefile如果不同模块之间编译参数差异极大或者有独立的单元测试组件再用递归方案。4.3 我把编译过程打印出来排查Makefile问题最狠的一个技巧就是使用make -n。这个参数表示“dry run”只打印会执行的命令但不会真的执行。比如你怀疑某条规则没有按照预期触发可以这样看make -n它会把整个构建过程要执行的命令全部摆在面前一目了然。另一个常用参数是make -p它会打印所有变量和规则的最终值适合排查变量覆盖、函数展开的问题。还有make -d会输出大量调试信息能让你看到make是如何决策每个目标的不过输出量真的很大一般配合重定向查看。另外建议在你的Makefile里加一个debug目标打印关键变量到底是什么debug: echo SRCS$(SRCS) echo OBJS$(OBJS)注意命令前的它的意思是执行命令时不把命令本身打印出来只打印输出结果。这个习惯能帮你省下大量猜变量值的时间。5. 实战中经常踩的坑和排查方法5.1 “make没有指明目标并且找不到makefile”这条报错是搜索引擎里常年热门的问题通常会在下面的场景出现你的当前目录下根本没有Makefile文件而你直接敲了make或者你的文件名写成了makefile.txt、Makefile.bak、MakeFile这类格式。make默认按顺序查找的文件名是GNUmakefile、makefile、Makefile。要注意的是Linux下文件名是严格区分大小写的Makefile和makefile是两个不同的文件。如果你两个都存在make会优先使用GNUmakefile然后是makefile最后才是Makefile。碰到这个报错第一步就是执行ls -l看看当前目录下有没有文件。如果文件存在但名字写错了用mv改回来就行。还有一个细节如果你在项目根目录执行make但Makefile放在build/子目录下也需要用make -C build指定目录。5.2 文件改了却不重新编译我吃过大亏的一个场景是改了某个.h头文件重新make结果程序行为一点变化都没有。原因多半是规则里没有把头文件写进依赖。比如前面的单文件规则%.o: %.c它只依赖.c文件头文件变了make却认为.o还足够新。解决办法有两个。一是简单粗暴在所有目标文件规则里都加上公共头文件%.o: %.c calc.h utils.h $(CC) $(CFLAGS) -c $ -o $二是用gcc自动生成头文件依赖gcc -MM -c main.c这个命令会输出类似于main.o: main.c /usr/include/stdio.h calc.h的依赖信息。实际操作中你可以让编译器自动生成.d文件再在Makefile中include这些文件这样头文件和源文件的依赖关系就能自动维护。这是工程级项目的标准做法不过因为篇幅有限这里先点到为止至少你应该知道还有这种依赖自动生成的机制。5.3 并行编译导致的问题make -j8确实能明显加快编译速度但当你用了递归Makefile或者规则里没有声明好依赖顺序时并行编译就可能出现“访问了还没生成的文件”这种问题。更隐蔽的是如果一个Makefile规则生成多个文件而另一个规则依赖其中某一个在并行模式下make可能无法正确推导导致偶发性的编译失败。我的经验是小项目没必要开并行大项目开并行前一定要确保每条规则的依赖都是完备的。出现偶发性失败时先把-j去掉看看是不是依赖缺失的问题。5.4 过滤与选择只编译某一个目标在大型项目里你可能只改了add.c根本不想链接整个calc。你可以直接指定目标make add.o这样make就只编译生成add.o不会去动其他文件。add.o如果能直接对应到一条规则make就会执行它。如果add.o又依赖add.c和calc.h它也会自动检查这两个文件的时间戳。这个小技巧特别适合排查某个模块能不能单独编译通过调试效率提升明显。5.5 常见错误速查报错信息常见原因解决方法missing separator命令前用了空格没用Tab缩进改为TabNo rule to make target xxx.o目标文件对应的源文件不存在或没有匹配的规则检查源文件路径和SRCS变量make: xxx is up to date.依赖文件没有比目标文件新或没有依赖被改变用make -B强制重新构建undefined reference to xxx链接时缺少目标文件或库确认OBJS是否包含所有.o文件multiple definition of xxx同一个符号在多处定义检查全局变量定义是否放到了头文件里/bin/sh: line 1: gcc: command not found没有安装编译器sudo apt install build-essentialDebian系或对应包管理器安装5.6 一个小技巧在Makefile里实现的增量编译验证最后分享一个我验证增量编译是否正常的方法。第一次执行完make后记录下calc这个可执行文件的修改时间然后故意用touch修改某个源文件的时间戳touch src/add.c make这时make会发现add.o比src/add.c旧于是只重新编译add.o并重新链接calc其他.o文件则原封不动。终端输出里只出现与add.c相关的编译命令。如果你看到全部文件重新编译了说明依赖关系设置得太宽泛比如把所有.h都加入了所有规则或者干脆OBJS这个变量没有达到预期的增量效果。6. 关于Makefile工具链的选择和一点个人心得写Makefile写到后面你会发现真正难的不是语法而是“如何清楚地表达项目各部分之间的关系”。很多人一上来就想着用自动生成工具比如cmake、autotools但我觉得学习Makefile本身的逻辑是绕不开的基本功。CMake确实能帮你生成Makefile但如果连目标、依赖、变量这些概念都不清晰出了问题根本无从下手。拿我个人来说这几年维护过的C/C项目既有老二进制的传统工程也有新写的几个私有工具链。我还是保留了一个习惯新项目只要规模不大宁可手动维护一个干净利落的Makefile而不是一上来就引入一套生成体系。为什么因为Makefile直观看一遍就知道整个构建过程是怎么走的而CMake的项目如果不是自己亲手写的我通常得花不少时间去查缓存、追变量才能搞明白某条路径为什么会被编译进去。当然如果你的项目要跨平台发布、需要依赖第三方库的自动探测那CMake几乎是必须的这点我并不反对。但Makefile作为底层的构建语言学懂它对理解CMake生成的日志、排查交叉编译的怪问题帮助非常大。如果是刚开始接触我建议你直接用这篇里的计算器示例把每个目标、每条依赖都亲手敲一遍。先跑通再尝试删掉一条依赖看看会发生什么再尝试引入一个变量看看能简化多少。等你能熟练地用wildcard、patsubst和模式规则组织一个多目录项目时你对“项目构建”这件事的掌控感就完全不一样了。 
长河君 · 2026/9/17 1:45:08 · 阅读 1.2k Makefile实战指南：从编译依赖到多目录构建的完整演进
很多朋友在Linux下写C/C代码时都有过这样的经历编译一个小项目在终端里一条条敲gcc命令文件少还好说文件一多或者换台机器重新编译就变成一场灾难。这时候Makefile就是那个能让你从重复劳动里解脱出来的东西。简单说Makefile就是一套编译脚本加依赖规则的组合你只需要敲一个make它就能按你定的规则完成编译、清理、安装等所有操作。这篇文章我会用一个完整的小项目手把手讲解Makefile的常用写法、变量与函数、多目录组织方式以及我在实际开发中踩过的坑适合刚接触Linux开发、想搞清楚make怎么用的读者。1. Makefile到底在解决什么问题1.1 从最原始的编译方式说起先还原一个真实场景。假设你要写一个简单的计算器程序代码拆成了下面这些文件main.c程序入口负责接收用户输入add.c/sub.c/mul.c/div.c四个运算模块calc.h公共头文件声明函数接口没有Makefile的时候你大概会这样编译gcc -c main.c -o main.o gcc -c add.c -o add.o gcc -c sub.c -o sub.o gcc -c mul.c -o mul.o gcc -c div.c -o div.o gcc main.o add.o sub.o mul.o div.o -o calc这个流程第一次跑没问题但第二次、第三次呢你改了一个add.c然后又要从头把五个文件全部编译一遍。如果工程里有几十上百个源文件这个重复编译的时间会让人非常崩溃。更麻烦的是你很难记住main.o到底依赖哪些头文件头文件更新了但对应的.o没重新编译最后链接出来的程序行为莫名其妙。Makefile解决的就是这两个核心问题一是把编译命令固化成一个可复用的流程二是在文件依赖关系的基础上实现增量编译——只重新编译那些真正发生了变化的源文件其余文件直接复用旧的.o文件。这第二点才是Makefile最值钱的地方它背后靠的是文件时间戳比较如果目标文件.o比依赖文件.c还要新说明源文件没改过这个目标就不需要重新构建。1.2 目标、依赖和规则的三角关系Makefile最基本的语法单元是“规则”结构是这样目标: 依赖 命令这里的“目标”通常是你想生成的文件比如main.o“依赖”是生成这个目标需要的东西比如main.c和calc.h而“命令”就是你实际要执行的动作比如gcc -c main.c。一个最容易忽略的细节是命令前必须是一个Tab字符不能是空格。我见过太多新手在这个地方栽跟头报错信息通常是missing separator。如果你用vscode或vim编辑Makefile建议把“显示不可见字符”打开确保缩进处是一个实实在在的Tab。Make的完整执行逻辑可以理解为三句话如果没有给make指定目标它就去找文件里第一条规则的目标来执行每个目标的依赖如果也是其他规则的目标就先递归构建那些依赖如果依赖文件比目标文件的时间戳还新就重新执行命令来更新目标这套机制看着简单但衍生出的变量、函数和自动化变量能让你的Makefile写得非常优雅。2. 从零手写一个Makefile单文件到多文件的完整演进2.1 单文件场景最小可用的Makefile我们先从最朴素的需求入手。只有一个hello.c编译成hello这个可执行文件。最直白的Makefile长这样hello: hello.c gcc hello.c -o hello clean: rm -f hello这里其实藏了一条Makefile的隐含规则。因为hello.c是存在的即使你不写依赖也能通过隐式规则编译出hello但那样做可读性太差也不利于后面的改造。上面的写法里一共有两条规则第一条目标是hello依赖hello.c第二条目标是clean没有依赖只负责清理文件。在终端执行makemake发现第一条目标是hello检查依赖hello.c存在且hello文件不存在或者比hello.c旧于是执行命令生成hello。再执行一次make它会提示“make: hello is up to date.”说明什么也不用做。这里就要引出一个概念如果clean这种目标并不真正生成一个文件而是执行一段动作那么它应该被声明为“伪目标”。否则如果当前目录下恰好存在一个名为clean的文件make会认为“clean”这个目标已经是最新的直接跳过执行rm命令就不会运行。解决办法是加上一句.PHONY: clean这样make就不会去检查有没有同名文件了。clean、all、install这类命令型目标最好都声明成.PHONY。2.2 多文件场景逐个写出所有规则回到计算器项目先写一个“老实人版本”的Makefilecalc: main.o add.o sub.o mul.o div.o gcc main.o add.o sub.o mul.o div.o -o calc main.o: main.c calc.h gcc -c main.c -o main.o add.o: add.c calc.h gcc -c add.c -o add.o sub.o: sub.c calc.h gcc -c sub.c -o sub.o mul.o: mul.c calc.h gcc -c mul.c -o mul.o div.o: div.c calc.h gcc -c div.c -o div.o clean: rm -f *.o calc .PHONY: clean这个写法能跑但问题也很明显每增加一个源文件就要多写两行如果改了编译器选项所有规则都要跟着改五条编译规则几乎一模一样唯一的区别就是文件名。这其实就是Makefile中“重复代码”的坏味道下一步必须引入变量和自动变量来消除。2.3 用变量和自动变量简化规则自动变量是make的内置变量只能在规则的命令部分使用。常用的三个是$代表当前规则的目标名$^代表所有依赖文件列表以空格分隔$代表依赖列表中的第一个依赖有了它们上面的编译规则就可以压缩成CC gcc CFLAGS -Wall -g calc: main.o add.o sub.o mul.o div.o $(CC) $^ -o $ %.o: %.c calc.h $(CC) $(CFLAGS) -c $ -o $ clean: rm -f *.o calc .PHONY: clean这里还用了一个“模式规则”%.o: %.c它表示“所有的.o文件都依赖同名的.c文件”。make遇到main.o这个目标时自动套用这条规则$就是main.c$就是main.o。这样不管以后加多少个源文件只要它们都依赖calc.h编译规则就不用再动。我第一次体会到自动变量的威力时真是有种写代码时的通透感。写Makefile和写程序是一样的事别重复自己。你越是把规则抽象出来后面改起来就越轻松。3. 进阶技巧变量、函数和模式规则组合起来用3.1 Makefile变量相当于代码里的常量Makefile里的变量非常简单用、:、?或来赋值。几种赋值方式看着相似实际意义不一样我建议一开始就搞清楚不然会碰到奇怪的问题。是递归展开赋值变量在真正使用的时候才展开。如果变量之间互相引用很容易出现无限递归或者取值不符合预期:是简单赋值在赋值时就立即展开右边的变量?是如果没有被赋值过才赋值适合给一些可覆盖的默认参数是追加赋值举一个区别的例子A 1 B $(A) A 2 C : 1 D : $(C) C : 2最终B的值是2因为B $(A)在取值时才去展开A而D的值是1因为在D : $(C)那一刻C已经被定死了。实际开发中我首选:避免后续变量被意外修改导致结果不可预测。常见变量的命名习惯如下CC : gcc CFLAGS : -Wall -Wextra -O2 -g LDFLAGS : -lm TARGET : calc SRCS : main.c add.c sub.c mul.c div.c OBJS : $(SRCS:.c.o)最后一行$(SRCS:.c.o)是变量替换引用把SRCS里所有.c后缀替换成.o等价于main.o add.o sub.o mul.o div.o。这个技巧可以避免你同时维护两份文件列表。3.2 常用函数wildcard、patsubst和foreach真正让Makefile变得灵活的是内建函数。先说最常用的wildcardSRCS : $(wildcard *.c)这行代码的意思是把当前目录下所有.c文件扩展成一个以空格分隔的列表。有了它你新增源文件后Makefile一行都不用改。配合patsubst可以做后缀替换OBJS : $(patsubst %.c, %.o, $(SRCS))这个写法和上面的$(SRCS:.c.o)效果一样但patsubst支持更复杂的模式比如匹配路径前缀。我曾经在把源码从src/目录重构到src/foo/目录的时候靠patsubst只改了一行就搞定了所有目标文件路径免去了逐个修改的麻烦。foreach函数则适合生成循环结构。比如你有几个子目录想要拼接出每个目录下所有.o文件的路径可以这样写SUBDIRS : src test tools OBJS : $(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.c))含义是对SUBDIRS中的每个目录名执行$(wildcard 目录/*.c)把所有结果拼在一起。这三个函数是Makefile里出现频率最高的熟练之后别说是单目录项目就是中型多目录项目也能用一份Makefile轻松管住。3.3 模式规则与内置隐含规则模式规则的核心就是一个带%的通配规则。前面写的%.o: %.c就是最典型的例子。它比写死每一条规则要灵活得多你甚至可以针对某一类文件专门定制编译参数# 普通源文件 %.o: %.c $(CC) $(CFLAGS) -c $ -o $ # 生成汇编文件 %.s: %.c $(CC) -S $(CFLAGS) $ -o $make本身还自带一堆隐含规则比如它知道.c文件可以编译成.o.o文件可以链接成可执行文件。如果你在规则里省略了命令部分make就会尝试用内置规则补齐。某些场景下这能节省不少代码量但也会带来“为什么它用的编译参数和我不一样”的困惑。我的建议是重要项目的编译命令要显式写清楚不要依赖隐含规则否则项目的可移植性会打折扣。4. 多目录工程怎样组织Makefile4.1 单Makefile方案一条规则通吃全部目录当项目结构变成这样时很多人会下意识地觉得需要每个子目录都放一个Makefile其实不一定project/ ├── Makefile ├── src/ │ ├── main.c │ └── calc/ │ ├── add.c │ ├── sub.c │ └── calc.h └── test/ └── test_main.c一个办法是用wildcard递归收集源文件再用patsubst批量生成目标文件最后通过VPATH或者直接带上目录前缀来访问头文件。一个比较简洁的写法是CC : gcc CFLAGS : -Wall -g -I./src/calc TARGET : calc SRCS : $(wildcard src/*.c src/calc/*.c test/*.c) OBJS : $(patsubst %.c, %.o, $(SRCS)) $(TARGET): $(OBJS) $(CC) $^ -o $ %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -rf $(OBJS) $(TARGET)这里-I./src/calc的作用是告诉编译器去src/calc目录下找头文件。%.o: %.c配合带目录的源文件路径生成的OBJS会是src/main.o、src/calc/add.o这样带路径的名字make会为每条规则先检查目录是否存在如果目录不存在就会报错。所以你需要确保这些中间目录是存在的一般源码都在不会有大问题。单Makefile方案的优点是逻辑集中全局依赖关系清晰调试相对容易缺点是工程一旦膨胀到几十个子目录这一个文件会很臃肿而且每次编译都要递归扫描所有目录效率会下降。4.2 递归Makefile方案子目录各自为政另一种常见做法是每个子目录一个Makefile再由顶层Makefile分发调用。每个子目录的Makefile只负责构建自己的目标通常长这样# src/calc/Makefile OBJS : add.o sub.o all: $(OBJS) %.o: %.c calc.h $(CC) $(CFLAGS) -c $ -o $顶层Makefile则遍历子目录SUBDIRS : src src/calc test all: for dir in $(SUBDIRS); do \ $(MAKE) -C $$dir; \ done clean: for dir in $(SUBDIRS); do \ $(MAKE) -C $$dir clean; \ done$(MAKE)是make的专有变量永远指向当前正在执行的make程序。这里必须用$(MAKE)而不是直接写make因为在并行编译make -j或者make被重命名时直接写make会出问题。递归Makefile的优点是把复杂的子任务拆开了每个目录可以有自己的编译参数、自己的清理逻辑缺点是依赖关系的管理比较麻烦如果你在顶层想判断某个子目录的东西是不是最新的就得一层层往下问构建速度反而可能变慢。很多大型项目就是用递归Makefile玩出花的。我的建议是如果你的工程在5个目录以内而且大家共享同一套头文件和编译选项优先用单Makefile如果不同模块之间编译参数差异极大或者有独立的单元测试组件再用递归方案。4.3 我把编译过程打印出来排查Makefile问题最狠的一个技巧就是使用make -n。这个参数表示“dry run”只打印会执行的命令但不会真的执行。比如你怀疑某条规则没有按照预期触发可以这样看make -n它会把整个构建过程要执行的命令全部摆在面前一目了然。另一个常用参数是make -p它会打印所有变量和规则的最终值适合排查变量覆盖、函数展开的问题。还有make -d会输出大量调试信息能让你看到make是如何决策每个目标的不过输出量真的很大一般配合重定向查看。另外建议在你的Makefile里加一个debug目标打印关键变量到底是什么debug: echo SRCS$(SRCS) echo OBJS$(OBJS)注意命令前的它的意思是执行命令时不把命令本身打印出来只打印输出结果。这个习惯能帮你省下大量猜变量值的时间。5. 实战中经常踩的坑和排查方法5.1 “make没有指明目标并且找不到makefile”这条报错是搜索引擎里常年热门的问题通常会在下面的场景出现你的当前目录下根本没有Makefile文件而你直接敲了make或者你的文件名写成了makefile.txt、Makefile.bak、MakeFile这类格式。make默认按顺序查找的文件名是GNUmakefile、makefile、Makefile。要注意的是Linux下文件名是严格区分大小写的Makefile和makefile是两个不同的文件。如果你两个都存在make会优先使用GNUmakefile然后是makefile最后才是Makefile。碰到这个报错第一步就是执行ls -l看看当前目录下有没有文件。如果文件存在但名字写错了用mv改回来就行。还有一个细节如果你在项目根目录执行make但Makefile放在build/子目录下也需要用make -C build指定目录。5.2 文件改了却不重新编译我吃过大亏的一个场景是改了某个.h头文件重新make结果程序行为一点变化都没有。原因多半是规则里没有把头文件写进依赖。比如前面的单文件规则%.o: %.c它只依赖.c文件头文件变了make却认为.o还足够新。解决办法有两个。一是简单粗暴在所有目标文件规则里都加上公共头文件%.o: %.c calc.h utils.h $(CC) $(CFLAGS) -c $ -o $二是用gcc自动生成头文件依赖gcc -MM -c main.c这个命令会输出类似于main.o: main.c /usr/include/stdio.h calc.h的依赖信息。实际操作中你可以让编译器自动生成.d文件再在Makefile中include这些文件这样头文件和源文件的依赖关系就能自动维护。这是工程级项目的标准做法不过因为篇幅有限这里先点到为止至少你应该知道还有这种依赖自动生成的机制。5.3 并行编译导致的问题make -j8确实能明显加快编译速度但当你用了递归Makefile或者规则里没有声明好依赖顺序时并行编译就可能出现“访问了还没生成的文件”这种问题。更隐蔽的是如果一个Makefile规则生成多个文件而另一个规则依赖其中某一个在并行模式下make可能无法正确推导导致偶发性的编译失败。我的经验是小项目没必要开并行大项目开并行前一定要确保每条规则的依赖都是完备的。出现偶发性失败时先把-j去掉看看是不是依赖缺失的问题。5.4 过滤与选择只编译某一个目标在大型项目里你可能只改了add.c根本不想链接整个calc。你可以直接指定目标make add.o这样make就只编译生成add.o不会去动其他文件。add.o如果能直接对应到一条规则make就会执行它。如果add.o又依赖add.c和calc.h它也会自动检查这两个文件的时间戳。这个小技巧特别适合排查某个模块能不能单独编译通过调试效率提升明显。5.5 常见错误速查报错信息常见原因解决方法missing separator命令前用了空格没用Tab缩进改为TabNo rule to make target xxx.o目标文件对应的源文件不存在或没有匹配的规则检查源文件路径和SRCS变量make: xxx is up to date.依赖文件没有比目标文件新或没有依赖被改变用make -B强制重新构建undefined reference to xxx链接时缺少目标文件或库确认OBJS是否包含所有.o文件multiple definition of xxx同一个符号在多处定义检查全局变量定义是否放到了头文件里/bin/sh: line 1: gcc: command not found没有安装编译器sudo apt install build-essentialDebian系或对应包管理器安装5.6 一个小技巧在Makefile里实现的增量编译验证最后分享一个我验证增量编译是否正常的方法。第一次执行完make后记录下calc这个可执行文件的修改时间然后故意用touch修改某个源文件的时间戳touch src/add.c make这时make会发现add.o比src/add.c旧于是只重新编译add.o并重新链接calc其他.o文件则原封不动。终端输出里只出现与add.c相关的编译命令。如果你看到全部文件重新编译了说明依赖关系设置得太宽泛比如把所有.h都加入了所有规则或者干脆OBJS这个变量没有达到预期的增量效果。6. 关于Makefile工具链的选择和一点个人心得写Makefile写到后面你会发现真正难的不是语法而是“如何清楚地表达项目各部分之间的关系”。很多人一上来就想着用自动生成工具比如cmake、autotools但我觉得学习Makefile本身的逻辑是绕不开的基本功。CMake确实能帮你生成Makefile但如果连目标、依赖、变量这些概念都不清晰出了问题根本无从下手。拿我个人来说这几年维护过的C/C项目既有老二进制的传统工程也有新写的几个私有工具链。我还是保留了一个习惯新项目只要规模不大宁可手动维护一个干净利落的Makefile而不是一上来就引入一套生成体系。为什么因为Makefile直观看一遍就知道整个构建过程是怎么走的而CMake的项目如果不是自己亲手写的我通常得花不少时间去查缓存、追变量才能搞明白某条路径为什么会被编译进去。当然如果你的项目要跨平台发布、需要依赖第三方库的自动探测那CMake几乎是必须的这点我并不反对。但Makefile作为底层的构建语言学懂它对理解CMake生成的日志、排查交叉编译的怪问题帮助非常大。如果是刚开始接触我建议你直接用这篇里的计算器示例把每个目标、每条依赖都亲手敲一遍。先跑通再尝试删掉一条依赖看看会发生什么再尝试引入一个变量看看能简化多少。等你能熟练地用wildcard、patsubst和模式规则组织一个多目录项目时你对“项目构建”这件事的掌控感就完全不一样了。