想象你是一位装修队的包工头。今天业主打电话说：“厨房的瓷砖有空鼓，帮我修一下。”你绝不会傻到把整栋房子推倒重建，而是翻开施工日志，找到厨房那一页：确认这面墙今天被动过、需要哪些材料、派哪个班组去，然后只修厨房，全屋其他地方原封不动。Make 就是软件开发界的这位包工头。它的施工日志叫 Makefile，里面记录着每件成品（目标）由哪些零件（依赖）拼成、用什么动作拼装（命令）。你只需敲下 make 三个字母，它就会自动检查：哪个成品还缺着、哪个零件比成品更新、哪些环节根本没变，然后把该干的活儿一口气干完，其余一概不碰。这篇文，我们就从包工头的视角，把 Makefile 的写法、变量、模式规则、伪目标，以及它和 CMake 的分工，讲得明明白白。

岗位关联

掌握 Make，你就能读懂并维护绝大多数开源项目的构建入口，排查编译问题不再是黑盒。这是 C/C++ 开发者必备的底层工具素养，也是通往构建系统设计思想的第一级台阶。

目录
  1. 可视化演示
  2. 认识Make工具：请来一位不拆家的包工头
  3. Makefile基本结构：施工日志的写法
  4. 变量与赋值：标准材料清单
  5. 伪目标与自动变量：不产出的管理任务
  6. 模式规则与函数：预制件模板
  7. C/C++实战运用：从毛坯到精装
  8. Make与CMake：设计院与包工头的分工
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

通过依赖追踪图、模式规则匹配、构建流水线三个模式，展示Make如何通过Makefile定义编译规则和依赖关系实现增量编译和自动化构建。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Makefile依赖追踪与增量编译 Make通过比较文件时间戳决定是否重新编译目标不存在或依赖更新则构建 增量编译仅重建变更文件及其下游依赖大幅减少编译时间 if dep.mtime > target.mtime: rebuild target 增量编译是Make核心价值10个文件仅改1个只重建3个

认识Make工具：请来一位不拆家的包工头

假设你是装修队的包工头，业主要求重铺厨房空鼓的瓷砖。你难道会把整栋楼的墙都推倒重砌吗？当然不会。你翻开施工日志，确认只有厨房这面墙被动过，然后调水泥、派瓦工，下午收工。可很多新手写 C 程序时干的就是傻事：改了一个文件，就把几百个文件全部重新编译一遍。Make 这位“包工头”，正是来终结这种无效劳动的。

Make 诞生于 1976 年，是贝尔实验室的 Stuart Feldman 在周末写出来的小工具，没想到一用就是半个世纪，成了 Unix/Linux 世界的事实标准。它的工作方式简单到令人吃惊：读一份名为 Makefile 的“施工日志”，里面每条记录说清楚“某件成品需要哪些材料、用什么动作做出来”，然后逐条检查、按需执行。你在终端敲下 make 三个字母，剩下的活它全包了。

Make 的核心聪明之处在于增量构建：它不靠猜，而是比较文件的时间戳（mtime）。对目标文件，只有两种情况需要重建：一是目标文件还不存在；二是某个依赖文件比目标文件更新——说明材料变了，成品该返工。其余情况一律跳过，连编译器都不调用。因此改一个 main.c，只有 main.o 和应用本体被重新生成，其他目标文件一秒带过。

这就好比包工头的智慧：他不是每天把整栋楼拆一遍来“确保安全”，而是只问一个问题——哪面墙今天被动过？只有被动过的墙才需要补。你省下的不仅是时间，更是大型项目从十几分钟编译压缩到几秒的巨大体验差距。

rebuild(t)  ⟺  ¬ ∃ target(t)  ∨  m(t)<m(d)\text{rebuild}(t) \iff \neg\, \exists\,\text{target}(t) \;\lor\; m(t) < m(d)
这句话是说：Make 要不要重做一件成品，只看两个条件——成品还没做出来，或者材料比成品新。两个条件满足任何一个，就开工。
  1. 目标不存在成品都没建出来，自然必须开工。
    ¬ ∃ target\neg\, \exists\,\text{target}
  2. 时间戳比较目标存在时比新旧，依赖比目标新就要返工。
    m(t)<m(d)m(t) < m(d)
  3. 或逻辑合并两种情况满足其一就触发，全不满足就跳过。
    A∨BA \lor B

Makefile基本结构：施工日志的写法

施工日志要记什么？日期、房间号、材料、施工动作。Makefile 的每条规则也是同样的三段式：目标、依赖、命令。目标就是你要做的成品，依赖是先决条件，命令是真正执行的动作。三者的分隔符很讲究：目标用冒号引出依赖，依赖列表用空格分隔，命令则必须缩进——注意，是 Tab 键，不是空格。

一套最朴素的规则长这样：app 依赖 main.o 和 utils.o，命令把这两个目标文件链接成可执行文件。如果 main.o 还不存在，Make 会先找有没有生成它的规则，一路追溯到源文件，自底向上把依赖链全部建好，最后执行 app 自己的命令。这种“先材料、后成品”的自底向上顺序，正是递归依赖解析的核心。

除了命令，Makefile 还有两个实用语法：以 # 开头的注释，说明这行是在干什么；行尾加反斜杠 \ 可以续行，把超长的命令拆成多行，可读性大幅提升。另外，直接运行 make 只会构建文件中第一个目标，所以工程惯例是把 all 写在最前面。

包工头拿到施工日志，不会关心日志纸的排版是否漂亮，只关心“成品—材料—动作”三要素齐不齐。Makefile 也一样，三要素齐了，Make 就能自动运转；写错缩进，整个日志就作废。

t:d1,d2,…,dn  ⇒  recipet : d_1, d_2, \dots, d_n \;\Rightarrow\; \text{recipe}
这条公式总结了规则的骨架：冒号左边是目标，右边是依赖清单，箭头指向的 recipe 是实际执行的构建命令。
  1. 目标名冒号左边是要生成的产物，如 app、main.o。
    tt
  2. 依赖清单冒号右边是材料列表，依赖的“新鲜度”决定是否重建。
    d1,d2,…,dnd_1, d_2, \dots, d_n
  3. 命令动作换行后以 Tab 开头的一串 Shell 命令，是真正干活的动作。
    recipe\text{recipe}
  4. 整体语义依赖全部就绪后，执行命令产出目标——材料齐了就开工。
    ⇒\Rightarrow

变量与赋值：标准材料清单

一个大工程里，编译器、编译选项、源文件列表会被反复引用。如果每处都写死，将来换编译器或加优化参数，就得全局搜索替换，想想就头疼。包工头的解决办法是“标准材料清单”：钢筋型号、水泥标号写在首页，各班组的活儿都对照首页执行。Make 的变量就是这张清单。

常见的做法是先定义 CC（C 编译器）、CFLAGS（编译选项）、OBJS（目标文件集合），然后在规则命令中用 $(变量名) 引用。好处立竿见影：想从 gcc 换成 clang，只改 CC := clang 一行；想开启调试符号，只改 CFLAGS 一处。所有规则共享同一份取值，既统一又不容易写错。

变量赋值有四种符号，语义各不相同，这是新手最容易踩的坑。= 是递归展开，只在引用时才现场求值，右侧内容会被后续修改影响；:= 是立即展开，赋值瞬间就定型，不受后续影响；?= 是条件赋值，仅在变量未定义时才生效；+= 是追加赋值，在原有值后面接上新内容。

用清单管理的好处是“一处修改，处处生效”。包工头把钢筋型号改了，全工地的班组自然按新规格干活；你把 CC 换成 clang，整个项目的编译命令随之更新，这就是变量的威力。

CC:=gcc,CFLAGS:=−O2 −Wall,OBJS:=main.o utils.o\text{CC} := gcc, \qquad \text{CFLAGS} := -O2\ -Wall, \qquad \text{OBJS} := \text{main.o}\ \text{utils.o}
一份标准清单样例：编译器、优化参数、目标文件列表统一在文件顶部定义，后面所有规则都引用这套清单。
  1. 立即展开赋值:= 在定义瞬间把右侧值算好定型，之后引用都是这份快照。
    x:=valuex := \text{value}
  2. 递归展开赋值= 只存“公式”，到使用时才现场算，后续改动会传导进来。
    x=valuex = \text{value}
  3. 引用取值无论哪种赋值，读取都用 $(名字)，像从清单首页取条目。
    $(x)⇒当前值\$(x) \Rightarrow \text{当前值}
  4. 条件与追加?= 仅在未定义时赋值，+= 在原有值后追加。
    x  ?=  a,x+=bx \;?=\; a, \qquad x += b

伪目标与自动变量：不产出的管理任务

工地上的任务不全是盖房子。安全检查、大扫除、清点材料，这些活儿不产出任何建筑构件，但也必须按时做。Makefile 里同样有一类“不产出文件”的目标，比如 clean（删除中间文件）、install（安装）、test（跑测试），它们叫伪目标。

伪目标最大的坑是：如果目录里恰好有一个叫 clean 的文件，Make 会认为“目标已存在且比依赖新”，于是拒绝执行命令。解决办法是显式声明：.PHONY: clean，告诉 Make“这个目标只是代号，别拿文件做比较，每次都给我执行”。同理还有 all、install 等管理类目标，都应该挂进 .PHONY。

为了写出通用规则，Make 提供了自动变量：规则内部不用写死文件名，直接用占位符。$@ 表示当前目标名，$< 表示第一个依赖，$^ 表示所有依赖（去重），$? 表示比目标还新的依赖。有了它们，一条规则就能服务任意文件名。

大扫除清单为什么每次都要重做？因为它不产出可比较的文件。伪目标就是给这类“管理任务”开的特权通道；自动变量则是让规则像表格公式一样，填什么行都成立。

$@=t,$<=d1,$={d1,…,dn},$?={di∣m(di)>m(t)}\$@ = t, \qquad \$< = d_1, \qquad \$^ = \{d_1,\dots,d_n\}, \qquad \$? = \{d_i \mid m(d_i) > m(t)\}
四个常用占位符：$@ 是目标自己，$< 是头号材料，$^ 是全部材料，$? 是“今天刚被动过”的材料——只需重补它们。
  1. $@ 目标名当前规则要生成的成品名，相当于“本工段交付物”。
    $@=t\$@ = t
  2. $< 首个依赖依赖列表第一项，常用于“用源文件编译出同名目标文件”。
    $<=d1\$< = d_1
  3. $^ 全部依赖去重后的完整材料清单，适合写进一条链接命令。
    $={d1,…,dn}\$^ = \{d_1,\dots,d_n\}
  4. $? 过期依赖只列出比目标新的依赖，实现“只补变坏的墙”。
    $?={di∣m(di)>m(t)}\$? = \{d_i \mid m(d_i) > m(t)\}

模式规则与函数：预制件模板

盖小区时，同户型楼栋的格局几乎一样，设计院出一套标准图纸，就能套用到所有楼。Make 的模式规则就是这个思路：用 % 作为通配符匹配任意“主干”，一条规则就覆盖所有相似文件。

最经典的写法是 %.o: %.c——任何 xxx.o 都由同名的 xxx.c 编译而来，规则命令里用 $< 取源文件、$@ 取目标文件。有了这条模式规则，你无需为每个 .c 文件手写规则，Make 会自动套用模板。再加上 wildcard 函数枚举目录里所有 .c 文件、patsubst 函数把后缀批量换成 .o，就能在文件顶部动态生成完整的目标文件清单，新增文件零成本。

函数是 Make 内置的“文本加工厂”：$(wildcard src/*.c) 返回匹配的文件列表，$(patsubst %.c,%.o, $(SRCS)) 把列表中的 .c 全部替换为 .o，$(basename ...)、$(notdir ...) 等还能进一步加工路径。它们与模式规则配合，是编写大型工程 Makefile 的基石。

一张户型图盖起整片小区，一条模式规则编译整个工程。你不再关心具体每个文件，而是定义“这类文件该怎么处理”，剩下交给模板批量执行。

%.o:%.c  ⟺  ∀s:  s.o:s.c  ⇒  gcc−c  s.c−o  s.o\% .o : \% .c \;\Longleftrightarrow\; \forall s:\; s.o : s.c \;\Rightarrow\; gcc -c\; s.c -o\; s.o
模式规则的本质是“对所有名字 s 成立”：任意 s.o 都依赖同名 s.c，并执行同一条编译命令。这就是一张万能户型图。
  1. % 通配符匹配任意文件主干 s，像“任何户型”的万能模板。
    %\%
  2. 同名映射s.o 来自同名 s.c，主干不变只换后缀。
    s.o↔s.cs.o \leftrightarrow s.c
  3. 批量转换函数patsubst 把源文件集合整体映射成目标文件集合，自动化生成清单。
    OBJS=patsubst(%.c,%.o,SRCS)\text{OBJS} = \text{patsubst}(\%.c,\%.o,\text{SRCS})

C/C++实战运用：从毛坯到精装

一套房子的交付要经过毛坯、水电、精装多道工序。C/C++ 工程的构建也分两个大阶段：编译和链接。编译阶段把每个 .c 源文件独立编译成 .o 目标文件，互不干扰；链接阶段把所有 .o 文件合并成最终的可执行文件。Makefile 正是把这条流水线固化成规则链。

一个中等规模的 C 工程，头文件管理、多目录、清理都是必修课。源文件里 #include "defs.h"，一旦头文件改动，所有包含它的源文件都该重编——所以规则里把头文件列为依赖；多目录工程用 VPATH 或 -I 指定搜索路径；make clean 负责删除所有 .o 和可执行文件，保证从零开始的全量构建。这些实践组合起来，才是一份能应付真实项目的 Makefile。

性能上，make -j4 可以并行构建互不依赖的目标（4 个任务同时跑），充分吃满多核 CPU；而增量构建让“改一行代码”的迭代从“全量重编几分钟”变成“重编一个文件几秒钟”。如果配合 $? 只针对过期依赖做处理，还能进一步压缩重建范围。

包工头不会因为修一面厨房的墙，就把整个小区的下水道重铺一遍。Make 的精髓同样如此：精确锁定变动，最小化返工，把工程师从漫长的全量编译等待中彻底解放出来。

app=link({ compile(si)∣si∈SRCS }),Tincr=∑i∈Δti≪Tfull\text{app} = \text{link}\Big( \{\, \text{compile}(s_i) \mid s_i \in \text{SRCS} \,\} \Big), \qquad T_{\text{incr}} = \sum_{i \in \Delta} t_i \ll T_{\text{full}}
构建总时长从“所有源文件的编译时间之和”缩小为“被改动波及的文件的时间之和”，增量构建因此能快上几十倍。
  1. 逐个编译每个源文件独立编译成 .o，改动互不影响。
    compile(si)→oi\text{compile}(s_i) \to o_i
  2. 统一链接所有 .o 汇合链接成可执行文件，这是最后一道总装工序。
    link({oi})→app\text{link}(\{o_i\}) \to \text{app}
  3. 增量集合只有被改动波及的环节进入重建集合 Δ，其余直接跳过。
    Δ={ i∣m(si)>m(oi) }\Delta = \{\, i \mid m(s_i) > m(o_i) \,\}
  4. 总耗时对比增量构建只花“补墙”的时间，远小于全屋翻新。
    Tincr≪TfullT_{\text{incr}} \ll T_{\text{full}}

Make与CMake：设计院与包工头的分工

很多新手把 Make 和 CMake 摆在对立面，以为它们是二选一的替代品。其实它们是构建流程中两个不同环节的伙伴。拿盖楼打比方：CMake 是设计院，负责出图纸；Make 是施工队，负责按图纸干活。设计院不搬砖，施工队不画图，二者缺一不可。

具体流程是：你写一份 CMakeLists.txt（图纸），运行 cmake 让它生成 Makefile（施工方案），再运行 make 完成实际编译。也就是说，CMake 是“生成器”，Make 是“执行器”。这也是为什么你用 CMake 构建项目时，最后总能看到 make 在跑——你看到的执行环节就是 Make 的舞台。

那么什么时候直接用 Make，什么时候交给 CMake？中小型 C 工程、纯 Make 脚本、需要细粒度控制编译细节的场景，直接写 Makefile 更轻快；跨平台的大型项目、需要自动查找第三方库、生成安装包和测试目标的项目，CMake 的抽象能力更省心。理解 Make 底层机制，反而能帮你读懂 CMake 生成的脚本，遇到问题知道去哪排查。

给 AI 从业者的建议是：先把 Make 这块“底层砖”摸熟，再上 CMake 会事半功倍。你看到的每一个 make 输出，背后都是一套清晰的依赖逻辑；掌握了它，任何构建系统对你都不再是黑盒。

CMakeLists→  cmake  Makefile→  make  app\text{CMakeLists} \xrightarrow{\;\text{cmake}\;} \text{Makefile} \xrightarrow{\;\text{make}\;} \text{app}
一条完整的构建流水线：设计院出图纸，施工队按图施工。CMake 管“生成规则”，Make 管“执行规则”，各司其职。
  1. 设计院画图cmake 读取 CMakeLists.txt，生成 Makefile 构建脚本。
    CMakeLists→cmakeMakefile\text{CMakeLists} \xrightarrow{\text{cmake}} \text{Makefile}
  2. 包工头施工make 执行 Makefile 里的规则，完成编译与链接。
    Makefile→makeapp\text{Makefile} \xrightarrow{\text{make}} \text{app}
  3. 分层协作两个工具处于不同抽象层，一上一下，互为上下游而非替代关系。
    上层生成→下层执行\text{上层生成} \rightarrow \text{下层执行}

AI 应用场景

开源 AI 推理引擎的部署编译

阶段：模型部署与推理优化

解决的问题：部署 llama.cpp、whisper.cpp 等 C/C++ 推理引擎时，传统方式要手敲十几条 gcc 命令，参数难记、顺序易错；Make 让 make -j4 一条命令完成依赖检查与增量编译，改完源码立刻增量重建，大幅缩短“改代码→看效果”的迭代回路。

具体案例：工程师 clone 下 llama.cpp 后执行 make -j4，首次全量编译需要几分钟；随后修改了 ggml.c 里的矩阵乘法算子，再次 make 只重编改动的文件和链接步骤，几秒出结果，正好对应“包工头只补坏墙”的增量智慧。

特征工程的流水线编排

阶段：数据工程

解决的问题：特征流水线包含“原始日志→清洗→切分→特征表”多个阶段，每阶段产出文件，人工记住调用顺序容易出错，全量重跑浪费时间；Make 天然适合表达文件间的依赖关系。

具体案例：数据团队在 Makefile 中定义 raw.log → clean.csv → train.tsv → features.npy 的依赖链，原始日志每天更新，执行 make features 时只有受影响的阶段被重跑，别的一律跳过。改动只需维护一份规则文件。

边缘设备的交叉编译管理

阶段：边缘设备部署

解决的问题：同一套 C 源码要编译出 x86 服务端、ARM 边缘盒子、Android 库等多个平台产物，命令参数各不相同容易混淆；Make 变量可以优雅地切换工具链。

具体案例：Makefile 顶部用 CROSS_COMPILE 变量控制编译器前缀，定义 make pc 与 make arm 两个入口，产物输出到不同目录互不污染。切换目标平台只需换一个变量，符合“标准材料清单”一处修改、处处生效的思想。

Python 演示

python59 行
import osimport time # 用字典模拟 Makefile 中的规则: 目标 -> (依赖列表, 构建命令)RULES = {    "app": (["main.o", "utils.o"], "gcc main.o utils.o -o app"),    "main.o": (["main.c", "defs.h"], "gcc -c main.c"),    "utils.o": (["utils.c", "defs.h"], "gcc -c utils.c"),}  def need_rebuild(target, deps):    """判断目标是否需要重建: 目标缺失, 或某个依赖比目标新"""    if not os.path.exists(target):        return True    target_time = os.path.getmtime(target)    for dep in deps:        if os.path.exists(dep) and os.path.getmtime(dep) > target_time:            return True    return False  def build(target, rules, visited=None):    """递归构建: 先保证依赖就绪, 再决定是否重建目标"""    if visited is None:        visited = set()    if target in visited:        return True    visited.add(target)    if target not in rules:        return os.path.exists(target)    deps, cmd = rules[target]    for dep in deps:        if not build(dep, rules, visited):            return False    if need_rebuild(target, deps):        print("执行:", cmd)        with open(target, "a"):            os.utime(target, None)    else:        print("跳过:", target, "(已是最新)")    return True  if __name__ == "__main__":    for f in ["main.c", "utils.c", "defs.h"]:        with open(f, "w"):            pass    print("=== 首次构建 ===")    build("app", RULES)    time.sleep(0.1)    print("\n=== 修改 main.c 后再次构建 ===")    with open("main.c", "w") as f:        f.write("int changed;\n")    build("app", RULES)    print("\n=== 清理测试文件 ===")    for f in ["main.c", "utils.c", "defs.h", "main.o", "utils.o", "app"]:        if os.path.exists(f):            os.remove(f)
目的：用 Python 模拟 Make 的核心机制——递归解析依赖、时间戳比较、增量构建，直观演示“改一个文件只重编受影响环节”的完整过程。
  1. RULES = {用字典把 Makefile 规则搬进代码：键是目标，值是“依赖列表 + 构建命令”
  2. def need_rebuild(target, deps):模拟 Make 的核心判断函数：这个目标要不要返工
  3. if not os.path.exists(target): return True目标文件都不存在，必然要开工，不用再比较
  4. os.path.getmtime(dep) > target_time:依赖比目标新，说明材料变了，必须重做
  5. def build(target, rules, visited=None):递归函数：想盖二楼，先确认一楼已经盖好
  6. visited.add(target)防止循环依赖导致无限递归，相当于给进过的工地房间打标记
  7. for dep in deps:自底向上，每个依赖都构建完才轮到目标自己
  8. os.utime(target, None)模拟编译完成：给成品盖上“刚刚完工”的时间戳

常见误区

误区我在学 C++，老师让我用 Make，所以我以为 Make 就是专门给 C/C++ 写的编译器，离开 C 语言它就没用了。

正解Make 是一个通用的任务编排工具，它的规则只是“如果这些文件比那个文件新，就执行这些命令”。编译 C/C++ 只是它最常见的用法之一。你完全可以用 Make 来发布网站、同步数据、生成文档、跑测试。它相当于包工头，什么活儿都能派，只是盖房子最常干的活恰好是砌墙。

为何常见：教程里几乎都用 C/C++ 举例，Make 和 gcc 同时出现，新手很容易把“构建工具”误解成“编译器”。

误区我以为 make 会把所有文件从头到尾重新编译一遍，所以项目一大了就不敢用，总觉得改一个文件要等好久。

正解make 的核心卖点恰恰是增量构建——它对比目标和依赖的修改时间，只有“目标不存在”或“依赖比目标新”才重建。没动过的文件一秒跳过。这正是它存在半个世纪的意义。如果遇到“每次都全量重编”的情况，多半是依赖声明不完整或误用了强制目标。

为何常见：初次使用不了解时间戳机制，容易把“首次构建很慢”当成“每次都很慢”，或者看到别人执行 make clean && make 就以为必须这么干。

误区编辑器里我按 Tab，它自动变成四个空格了，make 应该也能识别吧？怎么一运行就报 "missing separator"？

正解make 明确规定 recipe 的命令行必须以 Tab 开头，空格一律报错。这是无数新人的第一坑。你可以用 .RECIPEPREFIX 把前缀改成其他字符，但默认情况下，命令行前面的缩进必须是真实存在的 Tab 字符，不能是空格。

为何常见：现代编辑器默认把 Tab 转成空格，从网页或聊天工具复制代码时，制表符也会被悄悄替换成空格，肉眼根本看不出来。

误区现在大项目都用 CMake，Make 是老古董了，学了没用，直接把精力全花在 CMake 上就行。

正解CMake 是“生成器”，它本身不构建，而是生成 Makefile（或 Ninja）让 make 执行。二者根本不在同一层。很多 CMake 项目的构建日志里，你看到的底层执行器依然是 make。理解 Make 反而能帮你读懂 CMake 生成的脚本，排查编译问题更有底气。

为何常见：新手从高层的 CMakeLists 入手，看不到底层执行链，误以为 CMake 在直接调编译器，从而得出“Make 被淘汰”的错误结论。

误区我在 Makefile 里写了 clean 规则，但执行 `make clean` 却提示“不需要执行”，文件也没被删掉，是不是命令写错了？

正解如果当前目录恰好有一个名为 clean 的文件，make 会认为“目标已存在且比依赖新”，于是拒绝执行命令。需要把 clean 声明为伪目标（.PHONY: clean），make 才无条件执行。同理还有 all、install、test 这些管理类目标。

为何常见：我们习惯从“函数名字”的角度理解目标，而 make 只看文件系统——没有 .PHONY 声明，它就把目标当成真实的文件来比较。

面试题

Q1. Make 判断某个目标是否需要重新构建，最重要的依据是什么？

单选题 · easy

  • A.文件的大小
  • B.修改的时间← 正确答案
  • C.编译器的版本
  • D.代码的行数

答案：B。Make 用时间戳（mtime）判断新旧：依赖比目标新就要重建。它不关心文件大小、代码行数或编译器版本，只认谁更晚被改动，就像包工头只看“这面墙今天动没动过”。

Q2. 默认情况下，在工程目录里敲 make 会读取哪个文件？

单选题 · easy

  • A.Makefile← 正确答案
  • B.build.xml
  • C.CMakeLists.txt
  • D.setup.py

答案：A。make 默认按顺序查找 GNUmakefile、makefile、Makefile（常见写法是 Makefile）。CMakeLists.txt 是 CMake 的输入，build.xml 是 Ant 的，setup.py 是 Python 打包用的，都由别的工具读取。

Q3. Makefile 中，规则的命令行必须以什么字符开头？

单选题 · easy

  • A.四个空格
  • B.一个Tab← 正确答案
  • C.两个Tab
  • D.前后无所谓

答案：B。make 规定 recipe 命令必须以 Tab 开头，空格会直接报 "missing separator" 错误。这是新手入坑第一名的错误：编辑器把 Tab 自动转成空格，粘贴进 Makefile 就废了。

Q4. 在规则中，自动变量 \$@ 代表什么？

单选题 · mid

  • A.第一个依赖名
  • B.所有依赖集合
  • C.当前目标名字← 正确答案
  • D.当前目录路径

答案：C。\$@ 展开为当前规则的目标文件名；\$< 是第一个依赖；\$^ 是所有依赖。可以理解为包工头喊的代号：\$@ 就是“本工段要交付的那个成品”。

Q5. 为了避免目录里恰好有个叫 clean 的文件导致 make clean 失效，应如何处理 clean 目标？

单选题 · mid

  • A.声明为伪目标← 正确答案
  • B.加上FORCE标记
  • C.删除同名文件
  • D.改用大写名称

答案：A。把 clean 加入 .PHONY: clean 声明，make 就不再比较同名文件而是无条件执行命令。clean 是管理任务不是产物，像包工头的大扫除清单，不产出任何建筑构件，不能拿文件来比较。

Q6. 变量赋值中，符号：= 与 = 的主要区别是什么？

单选题 · mid

  • A.前者立即展开← 正确答案
  • B.前者递归展开
  • C.两者完全等价
  • D.前者是环境变量

答案：A。:= 在赋值瞬间把右侧值算好定型，= 则保存“表达式”到引用时才现场求值。前者像把材料清单当场打印固定，后者像口头说“到时候再看”，后续改动会传导进来。

Q7. 下列哪些属于 Make 的自动变量？

多选题 · hard

  • A.\$@ 代表目标名称← 正确答案
  • B.\$! 代表后台进程号
  • C.\$< 代表首个依赖← 正确答案
  • D.\$^ 代表全部依赖← 正确答案

答案：ACD。自动变量是 make 在每条规则里自动填好的占位符：\$@ 目标、\$< 首个依赖、\$^ 全部依赖，此外还有 \$? 和 \$*。\$! 是 Shell 里的后台任务进程号，并不是 Make 的自动变量。

Q8. 规则 %.o: %.c 的含义是什么？

单选题 · hard

  • A.只编译 main.o 一个目标
  • B.任意 .o 都由同名 .c 生成← 正确答案
  • C.删除所有中间产物
  • D.仅将文件后缀改为 .o

答案：B。% 是模式规则的通配符，匹配任意“主干”。这条规则声明：任何一个 xxx.o 都由同名 xxx.c 编译而来，一套模板服务所有源文件，不用为每个文件各写一条规则。

Q9. 关于 Make 与 CMake 的关系，下列说法正确的是？

多选题 · hard

  • A.CMake 可以生成 Makefile← 正确答案
  • B.Make 能读取 CMakeLists.txt
  • C.两者处于构建流程的不同环节← 正确答案
  • D.引入 CMake 后不会再生成 Makefile

答案：AC。CMake 是“生成器”，把 CMakeLists.txt 翻译成 Makefile（或 Ninja）；make 再执行 Makefile 完成编译。两者像设计院与包工头：设计院画图、包工头施工。B 和 D 都颠倒了分工。

Q10. 在 Makefile 中：先写 x = a，接着写 y = $(x)b，之后再写 x = c，问最后引用 \$(y) 的值是什么？

单选题 · extreme

  • A.ab
  • B.cb← 正确答案
  • C.ac
  • D.语法错误

答案：B。用 = 赋值是递归展开：y 只记住表达式 $(x)b，到被引用的那一刻才把 x 的当前值代入。此时 x 已是 c，所以 y = cb。若用 := 立即展开，y 才会固定为 ab。这是 Make 变量机制最经典的陷阱。