简介《makefile速成手册》是一份面向 Linux 驱动开发与工程构建场景的 GNU make 中文学习资料主要帮助读者理解 make 如何依据文件依赖关系和修改时间自动判断需要重新编译的文件解决大型项目中手工编译繁琐、易出错的问题。资源包内共 1 个 docx 文档整体约 66KB可在本地离线使用适合在开发电脑上随时打开查阅。文档内容从 make 概览与 makefile 基础规则入手依次介绍目标、依赖、命令写法、变量、特殊目标、隐含规则、函数、条件语句等常用知识点并专门整理 GNU make 的增强特性、与其他 make 工具不兼容的地方以及快速索引和选项总览便于读者按需定位。已有 182 人学习下载对想系统掌握 makefile 编写、提升自动化构建效率的 Linux 开发者来说是一份简明且实用的速查手册尤其适合在驱动或嵌入式项目中快速查阅构建规则。1. 先别急着复制别人的 makefile这份中文手册解决什么问题makefile 大概是 Linux 工程师身边最容易被复制粘贴的文件类型新工程来了从老项目拖一个模板改改目标名和源文件清单就交付。小工程能跑通可一旦涉及头文件变更、并行编译、交叉工具链翻车往往就从模板开始。这份《GNU make 中文手册》译本解决的是“知其然不知其所以然”的问题——把依赖关系、时间戳判断、变量展开、隐式规则这些底层机制摊开讲读下来拿到的不是语法表而是 make 的决策模型。适合两类人刚写 makefile 不久、想写对第一条规则的初学者模板用了很久、每次排查报错都要上网现搜的从业者。至于 make 和 cmake 怎么选建议先把这本手册过一遍cmake 生成的构建文件就是 Makefile看懂它很多 CMake 报错立刻能猜出原因。后面五章按“原理—实操—避坑—进阶”顺序带你把这份手册过一遍。2. 依赖和时间戳make 判断“要不要重编”的底层逻辑2.1 规则的四要素make 的整个工作方式浓缩成一句话就是根据依赖关系判断哪些目标需要更新然后执行对应的命令。这句话展开之后就是 makefile 里最基础的规则模板target ... : prerequisites ... recipe line 1 recipe line 2target 是你要生成的东西绝大多数情况下是一个文件名比如main.o或可执行文件editprerequisites 是生成 target 所依赖的文件可以是一个也可以是多个中间用空格隔开recipe 则是当 target 需要更新时make 要替你执行的 shell 命令。这个结构里有三个关键点需要单独说。第一recipe 的每一行开头必须是 Tab 键不是空格这是新手踩得最多的坑后面避坑章节会专门展开。第二target 不一定是文件也可以是一个动作的名字比如clean这种目标不对应任何磁盘文件。第三make 判断“是否需要更新”的唯一依据是文件的修改时间——如果 prerequisites 里有任何一个文件的修改时间比 target 新或者 target 本身不存在make 就认为这个目标过期了需要重新执行 recipe。main.o: main.c defs.h cc -c main.c上面这条规则的意思是main.o依赖main.c和defs.h如果这两个文件里有任何一个比main.o新或者main.o还不存在就执行cc -c main.c重新编译。注意make 根本不关心cc -c main.c这条命令具体做了什么它只负责在“需要更新”的时候把命令交给你指定的 shell 去执行然后根据退出码判断命令是否成功。这点理解不到位后面排查问题很容易走进死胡同。2.2 edit 工程一个 8 源文件的手写 makefile手册第二章用一个 8 个 C 源文件加 3 个头文件的编辑器工程做例子把最简单的完整 makefile 摆了出来。这个例子很经典值得完整看一遍# 注意cc 开头的行行首必须是 Tab 键 edit: main.o kbd.o command.o display.o \ insert.o search.o files.o utils.o cc -o edit main.o kbd.o command.o display.o \ insert.o search.o files.o utils.o main.o: main.c defs.h cc -c main.c kbd.o: kbd.c defs.h command.h cc -c kbd.c command.o: command.c defs.h command.h cc -c command.c display.o: display.c defs.h buffer.h cc -c display.c insert.o: insert.c defs.h buffer.h cc -c insert.c search.o: search.c defs.h buffer.h cc -c search.c files.o: files.c defs.h buffer.h command.h cc -c files.c utils.o: utils.c defs.h cc -c utils.c clean: rm edit main.o kbd.o command.o display.o \ insert.o search.o files.o utils.o反斜杠\的作用是续行把一行逻辑分成两行写让 makefile 更易读。注意反斜杠必须是一行的最后一个字符后面不能跟空格否则续行会失效这是这份手册里反复强调的一个细节。edit作为第一个目标也是默认目标直接执行make就会去构建它clean放在文件末尾只有你显式执行make clean时才会触发。2.3 执行顺序make 不是从上到下把命令跑完很多新手以为 make 会像 shell 脚本一样把 makefile 里的规则一行行执行下去这是最大的误解。make 的实际处理过程是先读整个 makefile找到默认目标edit然后发现它依赖 8 个 .o 文件于是先去处理这些 .o 文件的规则对每个 .o 文件再去检查它依赖的 .c 和 .h 文件的修改时间所有 .o 都处理完之后再回头看edit需不需要重新链接。手册里给了一个很好的推演如果你修改了insert.c然后执行 makemake 会重新编译insert.o因为insert.c比insert.o新其他 .o 文件的依赖都没变不会被重编最后因为insert.o比edit新所以执行链接命令生成新的edit。整个过程只编译了真正受影响的文件这就是增量编译的价值。# 场景修改 command.h 后执行 make # 哪些文件会被重编答案是kbd.o、command.o、files.o因为这三个文件都在自己的规则里声明了依赖command.h而main.o、insert.o这些没有声明依赖command.h的文件不会被动。这个“显式声明依赖”的习惯直接决定了你工程里一次源码改动会牵动多少文件参与重建。提示make 只认修改时间不认文件内容。哪怕你只是touch了一下defs.h内容一个字没改依赖它的 .o 文件也会被重新编译。反过来如果你把目标文件的修改时间改得比所有源文件都新那之后改了源码 make 也可能“看不见”——这就是所谓的“假新鲜”。3. 变量与隐式规则把 30 行 makefile 瘦到 15 行3.1 objects 变量上一章的 makefile 有个明显问题8 个 .o 文件名在edit的依赖和链接命令里写了两遍。如果以后新增一个window.o你得在两处都加上漏掉一处就是运行时链接错误或者依赖缺失。手册第 2.4 节给出的解法是变量。objects main.o kbd.o command.o display.o \ insert.o search.o files.o utils.o edit: $(objects) cc -o edit $(objects)objects是变量名$(objects)是引用变量的写法。make 在读取 makefile 的时候会把$(objects)展开成它后面的文本字符串效果等同于你在那个位置手动写下全部 .o 文件名。功能上类似 C 语言里的宏定义定义一次多处使用改一处就是改全部。变量名可以自由起但手册里建议在objects、OBJECTS、objs、OBJS这类约定俗成的名字里选一个别人接手时一眼就能看懂。这个习惯在你维护大型工程的时候能省掉很多沟通成本。注意变量定义时等号两边空格不影响结果但$(objects)里变量名拼错了 make 不会报错只会展开成空字符串——这种“静默失效”非常坑后面避坑章节会再提。3.2 隐式规则不写 recipe 也能编译上面的 makefile 里每个 .o 都配了一条cc -c xxx.c的 recipe写起来很啰嗦。实际上 GNU make 内置了一组隐式规则其中最常见的一条就是当目标是一个 .o 文件且目录下存在同名的 .c 文件时make 会自动使用cc -c命令来编译它。# 写法一显式写 recipe main.o: main.c defs.h cc -c main.c # 写法二省略 recipemake 自动推断 main.o: defs.h第二种写法能成立是因为 make 的隐式规则会自动把main.c加入main.o的 prerequisites。所以你可以把.c文件从依赖里省掉只保留头文件依赖make 也能正确地在main.c修改后触发重编。手册里还特别说明隐式规则的命令等价于cc -c main.c -o main.o注意它给输出文件加了-o参数。隐式规则不是魔法它靠的是文件名后缀匹配。.c对应.o这个映射关系是 GNU make 内置的如果你的源文件用的是其他后缀比如.cpp那对应的隐式规则会使用$(CXX)编译命令里用的编译器、编译选项都不同。想换编译器不用去改每条 recipe直接覆盖变量CC clang CFLAGS -Wall -gGNU make 内置的编译类隐式规则命令里写的是$(CC) $(CFLAGS)你只需在 makefile 里重新给这两个变量赋值整套编译命令就被替换成clang -Wall -g了。这也是为什么上手 makefile 时要先搞懂变量机制——隐式规则本身就是用变量拼出来的。3.3 头文件依赖要显式写隐式规则能帮你省掉 .c 文件但有一个边界它管不了头文件。make 不会去读取源文件源码不知道你的kbd.c里#include了哪些 .h所以头文件依赖必须由你在规则里显式写出来。这也是上一章那个示例 makefile 里每个 .o 目标后面都跟着一长串 .h 的原因。$(objects): defs.h kbd.o command.o files.o: command.h display.o insert.o search.o files.o: buffer.h这是手册第 2.6 节给的分组写法。第一条规则表示“所有 objects 里的 .o 文件都依赖 defs.h”下面两行表示“只有这几个特定的 .o 依赖 command.h / buffer.h”。files.o同时出现在两行实际依赖是并集。这种按依赖关系分组而不是按目标逐个写的风格更紧凑缺点是每个目标自己的依赖关系被拆散了看单个目标时不够直观。到底用哪种风格取决于你的偏好。关键是意识头文件依赖漏写后果就是“改了 .h 文件make 认为什么都没变产物还是旧的”这是工程里出现奇怪运行 bug 的头号来源。4. 伪目标与清理规则clean 为什么不能写在第一行4.1 伪目标 .PHONYclean大概是所有 makefile 里最常见的目标但它跟edit、main.o这类目标有本质区别它不对应任何真实文件只是一个动作名。问题来了——如果你的工程目录里恰好有一个文件叫clean那么 make 检查时间戳时会发现“目标文件已经存在”从而认为这个目标不需要执行make clean就什么都不干。.PHONY: clean clean: rm edit $(objects).PHONY声明告诉 make这个目标不指向真实文件不要拿文件时间戳去判断它是否需要更新只要被显式指定就无条件执行它下面的 recipe。这份手册里给出的实践是clean 规则一律配合.PHONY使用。同时.PHONY还有一个作用让 make 忽略rm命令返回的错误继续执行这个细节在清理场景里很实用因为目录里可能本来就没有某些 .o 文件rm会报“文件不存在”但不影响整体清理结果。提示.PHONY加在目标名之前可以声明多个伪目标比如.PHONY: clean distclean也可以在同一个 makefile 里多处出现。4.2 clean 的防呆写法实际工程里的 clean 规则我一般会在rm前面加一个-前缀这是 make 专门用来忽略单条命令错误退出的语法.PHONY: clean clean: -rm edit $(objects)-号的作用是即使rm返回非零退出码make 也把它当成可接受的结果继续执行后续命令。没有这个前缀rm 遇到不存在的文件返回错误make 默认会在第一条失败命令处停下。注意.PHONY声明之后clean 的 recipe 每次执行make clean都会被无条件触发——这是它方便的地方也是危险的地方一旦 recipe 里的命令写错比如把$(objects)写成了*.o或者在变量没定义时执行了rm -rf开头的命令你连“让 make 再判断一次是否真的需要删”的缓冲都没有。另一个容易忽略的约定是类似 clean 的规则不要放在 makefile 开头。make 默认目标是第一个目标如果clean被写在第一行那你执行make时它默认干的事就是清理目录而不是编译程序。手册里特意强调clean 放在最后不影响默认目标的确定也没有任何规则会把 clean 当依赖所以平时它永远不会被自动执行。4.3 用命令行参数控制 makemakefile 写清楚之后日常操作基本都在命令行上。除了直接make还有几个参数几乎每天都会用到make # 构建默认目标 make clean # 指定目标清理 make -j4 # 并行执行 4 个任务 make CCclang # 命令行覆盖变量 CC-j后面的数字是并行度在多核机器上能显著缩短构建时间但前提是你的依赖关系声明得足够完整——并行时 make 会同时跑多个 recipe一个目标等另一个目标输出的情况如果在 makefile 里没体现就可能出现“用半成品文件继续编译”的诡异错误。make CCclang这种写法是命令行变量覆盖它比 makefile 里的变量定义优先级更高临时换编译器或者调整构建参数时不用改文件适合在 CI 脚本里传参。GNU make 的变量优先级顺序越靠右优先级越高makefile 内定义 环境变量 命令行变量这个顺序手册里有详细说明调试时先判断变量值是从哪一层来的。5. 避坑记录五条 makefile 翻车现场5.1 报错行号、目标名和 error 1现象终端输出make[2]: *** [makefile:18: libs] error 1去翻 makefile 第 18 行怎么看都像是对的——依赖没错命令也没拼错。原因这个报错格式要拆开读[makefile:18: libs]表示 makefile 第 18 行的libs目标出问题error 1表示 recipe 里的 shell 命令返回了退出码 1。绝大多数情况下不是 makefile 语法错误而是“command failed”要么命令本身执行失败目录不存在、编译器没找到、链接库路径不对要么 recipe 行开头用的是空格而不是 Tab导致 make 压根没把这一行当成 recipe 来对待。解决先看错误里有没有具体的命令输出比如cc: command not found、No such file or directory有就直接修原因。命令输出为空再用make -n libs打印这个目标实际会执行的命令肉眼检查一遍。怀疑 Tab 问题就用cat -A makefile看行首recipe 行开头应该是^I如果是空格会在行首显示为空格而不是^I。血泪经验遇到 make 报错先花十秒确认 Tab再开始怀疑编译器。5.2 改了头文件却不重新编译现象改完defs.h里一个宏定义执行 make日志显示没有任何 .o 被重新编译可执行文件还是旧的。原因make 不读源码它只知道你写在规则里的依赖关系。隐式规则处理的是.c文件自动匹配头文件依赖如果没写进某个 .o 的规则那这个 .o 就永远不会因为 .h 的变化而重编。跟你是不是真的改了头文件没关系make 根本不知道有这个依赖存在。解决把 .h 依赖写全这是最直观的做法。但工程大了之后手写容易漏更通用的做法是让编译器帮你生成依赖文件gcc -MM main.c # 输出main.o: main.c defs.h-MM会扫描源码里的#include无视系统头文件输出 make 可以直接当规则用的格式。把每个 .c 的依赖输出到对应的.d文件然后在 makefile 里 include 进来-include $(objects:.o.d)$(objects:.o.d)是变量替换引用把main.o换成main.d展开后就是main.d kbd.d ...。行首的-表示 .d 文件不存在时也不报错第一次编译时没有 .d 文件很正常。配合下面的模式规则每次编译自动生成依赖文件%.d: %.c $(CC) -MM $ $$是 prerequisites 里的第一个文件$是目标名。这套组合是 C/C 工程里管理头文件依赖的标准做法比手写 .h 列表可靠得多。5.3 no rule to make target foo.o现象执行 make 直接停止报make: *** No rule to make target foo.o, needed by edit. Stop.原因foo.o出现在 edit 的依赖里但 makefile 里没有生成foo.o的规则磁盘上也不存在这个文件。常见原因三个源文件是Foo.c但依赖写成foo.oLinux 下大小写敏感直接找不到路径写错文件名写成了子目录里的名字但实际文件不在那新增了一个源文件objects 变量里加了但忘了main.c的规则名和实际文件名对不上。解决这个报错跟“permission denied”或者“file not found”不一样它表达的是“规则缺失”。先用ls确认磁盘上到底有没有这个 .o 文件和对应的 .c 文件文件名是不是大小写一致再核对 objects 变量最容易出问题是拼写。想快速看变量展开后的结果执行make -p | grep ^objects-p会把整个 makefile 的数据库打印出来包括所有变量最终值和内置规则排查时候非常有用。注意如果源文件是.cpp对应的目标后缀你可能写成了.o隐式规则会去找.cpp文件而不是.c这些细节都会在No rule报错里体现出来。5.4 clean 把源码删了现象执行make clean之后发现不仅是.o和执行文件没了某个目录下的.c源文件也不见了。原因最危险的一种是rm命令里用了未定义或空的变量。比如 recipe 写成rm -rf $(BUILD_DIR)但BUILD_DIR因为拼写错误或条件分支没走到而没有定义变量展开后命令变成rm -rf后面如果还跟了空格和通配符灾难就发生了。另一种常见原因是 clean 没声明.PHONY而你的工程里恰好有个文件和 clean 同名或同前缀make 的判断逻辑被绕进去了。通配符*.o在变量展开时匹配到的是当前目录所有 .o如果目录结构里混着不该删的东西也会一起被清掉。解决clean 规则务必放在.PHONY下这是第一道保险。命令执行前先演练一遍make 支持只打印不执行make -n clean这条命令会把 clean 要执行的命令原样打印出来但不去真的删文件。养成在删数据类目标之前跑-n的习惯比事后找备份可靠得多。另外建议变量都先给默认值比如BUILD_DIR ? build?表示变量没定义时才赋值这样即使某处没给它传值展开后至少不会变成危险的裸命令。5.5 反斜杠续行后的隐形空格现象makefile 里写得好好的objects main.o kbd.o \换行后继续insert.o search.o编译时报错说找不到insert.o看文件又确实存在。原因反斜杠是一行的结束符它后面如果跟了一个空格这个空格会变成“转义一部分”导致续行失效。更隐蔽的是变量值里可能被带进去一个多余的空格字符展开后变成insert.o前面有一个空格或者文件名和路径拼接出错。肉眼在普通编辑器里几乎看不出来因为行尾空格太容易被忽略了。解决开编辑器显示不可见字符vim 里执行:set list行尾空格会显示成$反斜杠后就藏不住东西了。不放心的话直接不拆行不到十个文件名一行也能放下。最靠谱的验证还是用make -p看变量展开后的最终值人眼猜不如看输出。从那以后我凡是用到续行的地方都会强制走一遍make -p确认变量内容再往下写规则。6. 调试手法-n、-p 与内核驱动场景的收尾6.1 先演练再执行make -nmake -n是个被低估的调试工具它让 make 把“将要执行什么命令”完整打印出来但不真的执行。改完 makefile 后先跑一遍make -n你能直观看到目标依赖、变量展开和命令拼接的全部结果。对clean这类毁灭性目标我尤其会先make -n clean再放行打印出来的rm -rf ...内容确认过才放心。6.2 把隐式规则摊开看make -pmake -p会把当前目录 makefile 的完整数据库输出到终端包括所有变量、显式规则、内置隐式规则和文件时间戳信息。排查“为什么这个目标没有重编”时先执行make -p | grep ^main.o看目标的实际依赖和更新时间再对照源文件时间戳基本几分钟就能定位问题。配合--debugv可以看到 make 逐条比较时间戳的决策过程比盲猜高效得多。这份手册我个人习惯放在手边当词典用遇到模糊语法先查第 6 章变量和第 10 章隐式规则基本都能找到答案。内核模块和驱动子目录里 Kbuild 体系本质上也构建在这些 GNU make 机制之上把变量覆盖、隐式规则、伪目标这三样吃透看驱动层 Makefile 就不会像看天书了。希望帮到你。本文还有配套的精品资源点击获取