简介《GNU Make 使用手册》是一份面向Linux开发者与GCC编程者的中文进阶资料重点讲解自动化构建工具GNU Make的工作原理与Makefile编写方法。手册从Make概述与规则格式入手先以hello程序为例展示目标、依赖项和命令的写法再解读make判断依赖更新并执行命令的完整过程并说明使用变量简化命令、按扩展名自动推断编译命令、以及clean规则清理临时文件的方法让读者快速建立清晰的构建逻辑。后续章节进一步覆盖多目标、模式规则、隐含规则、条件语句、函数与调试技巧并延伸至多级目录、跨平台构建等高级主题基本涵盖从基础到进阶所需的核心知识书中还专门讨论了如何调试Makefile以及常见问题和BUG的处理思路。压缩包内含1个PDF文件总大小705KB该中文版由于凤昌翻译以GNU Make 3.79版英文手册为基础目录分类清楚共分多个章节逐步深入。已有178人学习下载系统学习后读者能独立编写高效且易维护的Makefile为深入理解Linux内核源码或GCC工程构建打下扎实基础。1. GNU Make 使用手册为什么 3.79 版的中译手册到今天还能救急读 Linux 内核源码大部分人不是被 C 语法卡住的而是被那一层套一层的 Makefile 劝退的。这份 GNU Make 使用手册 3.79 中译版于凤昌先生翻译的版本把 make 的工作原理从规则格式讲到变量展开、隐含规则链和递归调用正好击中这个痛点。它和网上零散教程最大的区别是会把“make 为什么会这样行动”讲清楚而不是给几段能跑的片段就算完事。适合两类人刚接触构建系统的新手可以按前几章把最小工程串起来被诡异构建行为折磨过的熟手把后半部分的函数、隐含规则、运行参数当字典备查救急特别好用。2. 编写规则与依赖Makefile 的骨架和 make 的决策过程2.1 规则的基本格式目标、依赖、命令缺一不可手册 2.1 节给出了规则的完整格式目标target、依赖prerequisites、命令recipe。目标通常是要生成的文件依赖是目标生成前需要先准备好的文件或其它目标命令则是依赖比目标新时需要执行的 Shell 指令。命令部分有一个历史包袱每一行必须以真实的 Tab 开头空格不行这是无数人第一次写 Makefile 就翻车的地方。hello: hello.c gcc -o hello hello.c这条规则的意思是如果 hello.c 的修改时间比 hello 新make 就执行gcc -o hello hello.c。如果 hello 已经存在且比 hello.c 新make 会提示目标是最新的什么也不做。make 判断“要不要更新”只看时间戳不看文件内容所以同一秒内连续改两个文件、时间戳相等时它可能漏判——这种问题现象很怪原因往往出在文件系统时间戳精度上。注意Makefile 命令行的 Tab 必须是真实制表符编辑器如果自动把 Tab 转成 4 空格make 会直接报“missing separator”。2.2 一个能用的多文件工程 Makefile只写一条规则没多大意义。实际的工程最少也要解决三件事编译器参数可改、中间文件可清理、目标可配置。手册 2.4 节介绍了变量用法把 gcc 写死成占位符就能解决参数可改的问题。CC : gcc CFLAGS : -Wall -O2 OBJS : foo.o bar.o HEADERS : foo.h bar.h app: $(OBJS) $(CC) $(CFLAGS) -o $ $(OBJS) foo.o: foo.c $(HEADERS) $(CC) $(CFLAGS) -c foo.c -o $ bar.o: bar.c $(HEADERS) $(CC) $(CFLAGS) -c bar.c -o $ clean: rm -f $(OBJS) app这里的$是自动变量代表当前规则的目标名$^代表所有依赖$代表第一个依赖。把 OBJS、CFLAGS 提到顶部后续换编译器、加告警开关只需要改一处。注意 clean 这一条它没有生成任何文件却是一个标准动作型目标纯做清理不产生叫 clean 的文件。这引出了一个问题一个不生成文件的目标凭什么让 make 每次都执行看 2.3 节。2.3 特殊目标.PHONY、.DEFAULT、.PRECIOUS 各管什么事手册 4.7 节列出了一整组内建的特殊目标名。最常用的是 .PHONY它专门声明“这个目标不是文件”。光写 clean 而不加.PHONY: clean一旦目录里恰好存在一个名为 clean 的文件make 就会认为 clean 已经是最新的你的清理命令永远不会执行这是经典翻车现场。特殊目标作用高频使用场景.PHONY声明目标为伪目标不检查文件时间戳clean、install、all 这类动作型目标.SUFFIXES管理后缀规则列表清空可关闭老式后缀推断需要兼容老 makefile 时用到.DEFAULT没有任何规则匹配时执行其命令提示未知文件、统一报错信息.PRECIOUS构建中断时不删除该目标文件保护编译到一半的关键产物.SILENT不回显该目标的命令打包脚本、输出太长的发布流程.PRECIOUS是个冷门但趁手的工具并行构建时如果一个目标的命令失败make 默认会把已经生成了一半的目标文件当作临时文件清掉某些场景下你反而希望保留现场来排查这时候把它挂进 .PRECIOUS 就很合适。手册 4.7 节对每个特殊目标都有定义建议翻一遍哪怕是 .IGNORE 这种平常用不上的也能帮你理解“为什么 make 不按我想的报错”。2.4 命令里的三个不起眼符号、-、Tab规则里的命令区三个符号的语义是最容易被忽略的。手册 5.1 到 5.4 节专门讲命令回显和错误处理。命令默认会被回显到终端再执行在命令行前加能关掉回显适合 clean 里那类rm -f的噪音输出。命令前加-表示这条命令出错时 make 不中断继续执行后续命令适合“清理时目录里本来就没有这个文件”的宽容场景。clean: -rm -f $(OBJS) app echo cleaned.还有一个反直觉点make 的每条 recipe 都是在独立的 Shell 进程里执行的。伪目标下面的多条命令如果需要共享 cd 的操作环境写在两行里是失效的。手册 5.2 节明确写了这个限制常见做法是把切换目录和后续操作合并到一行用cd subdir $(MAKE) all这样只有一条 Shell 命令状态能传进去。这个“一行内做状态切换”的习惯在写多级目录递归构建时几乎天天用。3. 使用变量与函数把 Makefile 从写死改成可维护3.1 两类变量展开 与 : 的时机差别手册 6.2 节把变量分为递归展开变量和简单展开变量两种。用赋值的在引用时才对整个引用链做展开用:赋值的在赋值时立刻展开。这个差别平时没感觉一旦出现交叉引用就会变成玄学问题。A $(B) B cc C : $(B) B gcc all: echo A$(A) C$(C)执行结果里 A 在引用时展开能拿到赋值后的 gccC 在执行:那行时就已经把当时的 B 展开成了 cc之后 B 再变不影响 C。这个例子在手册 6.2 节有更完整的描述实际项目里最常见的坑是用定义的变量里引用了另一个变量而后者是在更后面的 include 文件里才赋值的导致展开结果被延迟到使用那一刻行为看起来像“变量值突然变了”。默认建议是内部计算类的变量用:需要延迟决定的可选项用。3.2 手动追加与强制覆盖、? 与 override变量定义除了和:还有追加语法以及条件赋值?。在变量后面追加内容适合让外部传入的 CFLAGS 与内部默认值共存?只在变量尚未定义时赋值适合给用户保留覆盖权。随后是变量优先级问题。手册 9.5 节讲了变量重载命令行上写make CFLAGS-g会直接覆盖 Makefile 里的赋值除非这个变量用了override指令。这是个双刃剑用户能从命令行覆盖编译器参数是 GNU Make 的惯例但项目里如果有一些强制宏不能被人覆盖就得用override CFLAGS -DREQUIRED1来兜底。手册 6.7 节专门讲了 override建议连同 9.5 节一起读否则发布出去的 Makefile用户很容易在命令行里无意打爆你的编译参数。CC ? gcc CFLAGS : -Wall -O2 override CFLAGS -D__OUTPUT_MODE13.3 文本函数subst、patsubst、wildcard 怎么配合手册第八章把函数调用统一写成$(函数名 参数…)的形式参数之间用逗号分隔。最常用的三类字符串替换类、文件名处理类、流程控制类。构建一个 src 到 obj 的映射是 patsubst 和 wildcard 的经典组合。SRCS : $(wildcard src/*.c) OBJS : $(patsubst src/%.c,build/%.o,$(SRCS)) $(OBJS): build/%.o: src/%.c mkdir -p build $(CC) $(CFLAGS) -c $ -o $wildcard把 src 目录下所有 .c 文件展开成一个列表patsubst把列表里的src/foo.c换成build/foo.o然后把每个 .o 文件映射到静态模式规则规则里用$取第一个依赖作为编译输入。这一套下来比手写十条等价规则少得多还能避免漏文件。函数章节里还有 subst、filter、sort、word 等一批小工具手册 8.2 到 8.3 节都有对应例子我在项目里用到频率最高的是 patsubst、wildcard、filter、sort。3.4 call、origin、shell变量调试三板斧调试 Makefile 最痛苦的是不知道变量从哪来。手册 8.7 节的origin函数直接告诉你变量的来源命令行的、环境的、makefile 里定义的、还是内建默认值一目了然。配合call函数还能把一段重复的逻辑抽成模板。define echo-var $(info $1 $($1) origin: $(origin $1)) endef $(call echo-var,CC) $(call echo-var,CFLAGS)这套写法相当于给 Makefile 加了个临时 printf。$(info …)在解析阶段输出能看到变量展开后的最终值$(origin …)告诉你这个值是哪里给的是环境变量继承来的、命令行来的还是 makefile 自己写的。如果一连串变量互相引用可以在关键节点插几个这样的 echo-var看变量在哪一步被改掉的。这个技巧在调复杂构建时比加注释管用得多我每次排查“变量怎么变成这个值”都用它手册 8.6 到 8.7 节给了 call 和 origin 的完整语法。4. Makefile 排查手册五条高频翻车记录与避坑思路4.1 报错“没有指明目标并且找不到 makefile”现象在项目根目录执行 make终端直接输出make: *** 没有指明目标并且找不到 makefile。停止。。原因make 默认按 GNUmakefile、makefile、Makefile 三个名字依次查找当前目录不合适、文件名大小写不对、或者文件在不同的子目录里都会命中这个缺省行为。还有一种情况是环境变量 MAKEFILES 里引用了不存在的文件也会让读取阶段失败。解决先确认所在目录再看文件名是不是 Makefile 而不是 makefile 或 MAKEFILE如果文件确实在别的目录用make -f path/to/Makefile显式指定。检查 MAKEFILES 环境变量有没有残留env | grep MAKEFILES能快速确认。4.2 Windows 下报“无法将‘make’项识别为 cmdlet”现象在 Windows 的 PowerShell 或 VSCode 终端里运行 make报无法将“make”项识别为 cmdlet、函数、脚本文件或可运行程序的名称或者在 cmd 里报“不是内部或外部命令”。原因make.exe 所在的目录没有加入 PATH。GNU Make 在 Windows 上通常是独立安装或伴随工具链分发装完后不会自动进系统环境变量。VSCode 里更特殊它是从资源管理器打开的可能继承了不完整的用户 PATH。解决把 make.exe 所在目录手动加到系统 PATH。在 VSCode 里改完环境变量后必须重新启动整个终端进程光重载窗口不够。如果用的是包管理器安装确认安装路径里是bin/make.exe还是直接叫 make.exe路径写错了照样找不着。4.3 无 sudo 时 make install 写不进系统目录现象普通用户执行make install在复制阶段报Permission denied整个安装流程中断。原因手册 14.2 到 14.4 节说明了安装惯例缺省 install 会把二进制装到 /usr/local/bin把库装到 /usr/local/lib这两个目录普通用户默认没有写权限。编译阶段没问题偏偏卡在最后安装特别像“构建成功了但发布失败”。解决安装阶段必须能指定前缀。常见做法是./configure --prefix$HOME/.local或者运行make install DESTDIR~/staging先装进临时目录再手动调整。README 里如果给了 prefix 参数构建前就要带上因为 prefix 会影响编译期的安装路径推断等到 install 再改已经晚了。4.4 clean 不删文件伪目标被同名文件挡住现象在项目里执行make clean没有任何输出或者提示make: clean is up to date编译产物一个没少。原因make 默认把目标当成一个文件路径目录里如果恰好存在一个叫 clean 的文件它会拿这个文件的时间戳和依赖比较发现不需要更新就直接跳过。伪目标是教学中最先讲、实操中最容易漏的一条。解决在 Makefile 显式声明.PHONY: clean同样需要挂进 .PHONY 的还有 all、install、test 这类动作目标。手册 4.4 节专门讲了假想目标里面的说法“声明一个目标不代表文件系统里一定要有同名文件”值得多看两遍。养成的习惯是每次新增一个动作型目标顺手把它追加到 .PHONY 行尾部。4.5 并行构建偶发文件缺失或行为不一致现象make -j8编译大型项目时某个中间文件时有时无或者出现两个规则同时写一个文件串行执行完全正常一加 -j 就出问题。原因并行模式下 make 同时执行互不依赖的命令如果两个目标依赖同一个中间文件、又没有显式声明这个中间文件是哪个目标产生的make 的依赖图里会出现竞争。手册 5.3 节对并行执行有说明隐含规则链在并行展开时尤其容易触发这种竞争。解决先make -j1跑一遍确认串行能过再加 -j 复现。检查并发目标之间有没有真实依赖被漏掉比如生成头文件的规则没有写进依赖列表。对构建过程中由脚本生成的中间文件用.PRECIOUS保护或者把自动生成依赖的规则挂到对应目标前面确保它先于使用它的规则完成。实在查不出来先用make -j2小并行度跑能显著降低偶发概率这是排查并行问题的临时后悔药。5. 隐含规则、自动依赖与递归构建拼一个真实项目的 Makefile5.1 隐含规则链make 默认知道怎么把 .c 变成 .o手册第十章花了一整章讲隐含规则。它的价值在于make 内置了一组“见到 .c 就按 cc 编译出 .o”这类默认配方你可以只写目标不写命令。比如目录里只有 foo.c执行make foomake 会自动推导出从 foo.c 编译到 foo 的完整链路手册 10.1 节给的就是这个例子。foo: foo.o就这一行规则配合内建的隐含规则make 就能把 foo.o 也推导出来再用链接命令生成 foo。这个机制对简化 Makefile 很有用但默认行为依赖隐含规则变量表CC 默认是 ccCFLAGS 默认是空LDLIBS 默认是空链接这一步用的是$(CC) $(LDFLAGS) foo.o $(LDLIBS) -o foo。变量默认值说明CCccC 编译器命令CFLAGS空C 编译参数CPPFLAGS空预处理参数常放 -I 路径LDFLAGS空链接参数LDLIBS空链接库放 -l 的位置隐含规则的默认值足够应付教学示例但真实项目必须在 Makefile 里显式重写这些变量否则出现“我明明装好了库为什么链接不上”的问题多半是 LDLIBS 里没写库名或者 CPPFLAGS 里漏了头文件路径。5.2 用 gcc -MM 自动生成头文件依赖手工在 Makefile 里写每个 .o 依赖哪几个 .h文件一多必然维护崩溃。手册 4.12 节讲了自动生成依赖的思路让编译器替你把依赖关系写出来。gcc 的 -MM 参数能输出“目标文件依赖于哪些源文件和头文件”的 make 格式规则把输出存成 .d 文件再 include 进来就能让 make 感知头文件变化。DEPS : $(OBJS:.o.d) $(DEPS): %.d: %.c $(CC) -MM $(CPPFLAGS) $ $ -include $(DEPS)这段的机制是把每个 .o 的依赖源文件映射到同名 .d.d 由编译器的 -MM 生成内容形如foo.o: foo.c foo.h bar.hinclude 进来后 make 就认为 foo.o 依赖这些头文件头文件一改目标自动重建。要点有两个-MM 是只输出依赖、不编译的参数必须在 CPPFLAGS 里带上所有 -I 路径否则头文件的依赖关系不全首次构建时 .d 文件还不存在所以要写成-include而不是include前者对不存在的文件不报错。我第一次跑这套就栽在第二次构建才生成依赖文件上后来强制第一次先跑make depend之类的前置目标就不会卡壳。5.3 递归 make$(MAKE) 与 -C 的配合多模块项目里子目录各自维护 Makefile顶层用递归方式调用它们。手册 5.6 节专门讲了递归调用最核心的一条是用$(MAKE)而不是make前者会把当前 make 进程收到的参数、命令行变量原样传给子 make后者不行。subsystem: $(MAKE) -C src all $(MAKE) -C lib all-C src让 make 先切到 src 目录再执行等价于cd src $(MAKE)但传参和错误回溯都比手写 cd 干净。递归调用最隐蔽的坑是 MAKEFLAGS 的传递父 make 的 -j 会被子 make 继承如果各个子目录的构建有隐藏的相互依赖并行递归很容易把共享的中间文件踩掉。我的习惯是显式控制递归的并行策略顶层决定 -j 数量子目录按需$(MAKE) -j1串行构建防止两个子模块同时写同一个生成文件。5.4 安装阶段prefix、exec_prefix 与 DESTDIR手册 14.4 节给出了 GNU 惯例里的安装路径变量这一节对发布软件的人很实用。prefix 是安装根默认 /usr/localexec_prefix 默认等于 prefixbindir、libdir、includedir 等从它们派生。跨发行版打包时DESTDIR 用于把安装的“真实根目录”临时指到打包目录这样make install DESTDIR/tmp/pkg会把文件装到 /tmp/pkg/usr/local/bin 这种结构下打包工具再用这些文件做压缩包。prefix : /usr/local exec_prefix : $(prefix) bindir : $(exec_prefix)/bin libdir : $(exec_prefix)/lib install: app install -d $(DESTDIR)$(bindir) install -m 0755 app $(DESTDIR)$(bindir)/appinstall 命令的 -d 负责创建目录-m 指定权限这种做法比 cp 更符合安装惯例也会自动处理目录不存在的情况。把 prefix、bindir 全部提升为变量用户就可以在命令行覆盖make install prefix$HOME/.local不污染系统目录。这套变量体系在手册 14 章有完整列表包括 datadir、sysconfdir、localstatedir做一个需要发布给别人的项目提前把变量设计成可覆盖后续打各发行版包会非常省事。6. Makefile 的验证与调试把 make 变成可观测的构建工具6.1 make -n 预演动手之前先看 make 想干什么make -n只打印将要执行的命令不真正执行。手册 9.2 到 9.7 节是运行 make 的参数全集-n 是我用得最勤的一个拿到别人的 Makefile先make -n看一遍命令列表确认没有脏东西再真正动工。配合make -n -p还能把整个 make 数据库变量最终值、全部规则解析结果一次性 dump 到终端用 grep 定位某个变量的来源。make -n | less make -np 2/dev/null | grep -A2 ^CFLAGSmake -np的输出很庞大grep 之前可以先重定向到文件再搜索避免终端刷屏把关键信息淹没。需要看某个目标依赖树时手册 9.7 节提到的--debugv也能输出详细的处理过程verbose 模式下每个比较、每次隐含规则匹配都会留痕。6.2 变量追踪习惯第一件事先拉变量表调试 Makefile 最容易陷入“猜”的状态。手册第 6 章和第 8 章的变量与函数配合-p打印数据库能解决 90% 的“变量值不对”问题。我这两年养成的习惯是拿到陌生 Makefile先make -n预演再make -p | grep -E ^(CC|CFLAGS|CPPFLAGS)把编译器相关变量拉出来确认编译参数和预期一致再动工。如果变量被命令行覆盖输出里会直接用 make 数据库标注出来不用再瞎猜。这个习惯救过我一次一个项目依赖一个第三方库头文件路径在 CPPFLAGS 里写死了我改了 Makefile 里的值但命令行缓存的 make 参数把它覆盖回去构建一直用旧路径。跑一次make -p拉变量表直接看到 CPPFLAGS 不是 Makefile 里的值检查 shell 历史才发现命令参数里带了一串残留变量。从那以后我每次接触有递归调用的 Makefile第一件事就是make -n预演、make -p拉变量表确认命令和变量都符合预期才继续这套流程比对着报错信息反向猜变量快得多。希望帮到你。本文还有配套的精品资源点击获取