我先讲一个自己踩过的坑。有一回调试一块嵌入式板卡，交叉编译老是找不到头文件，我在网上翻了好几圈帖子，最后才发现其实是 Makefile 里的头文件路径变量被环境变量静默覆盖了。当时要是早点把变量打出来，大概十分钟就能定位问题，结果白折腾了半天。从那以后我养成了一个习惯：遇到任何构建问题，第一件事不是翻文档，而是先把变量打印出来。
Makefile 里打印变量这个需求看起来再简单不过，但真正操作起来，里面还是有不少细节值得掰扯。你可能会想，不就是echo一下吗？实际上 Makefile 的变量展开有解析阶段和执行阶段之分，变量来源也分命令行、环境变量、内部定义好几类，打印方法和时机一旦选错，打出来的东西只会误导你。这篇就把 Makefile 打印变量的方法、原理、坑和实战挨个过一遍，适合刚入门的开发者，也适合在嵌入式交叉编译场景里折腾的老手看看。
1. 为什么要在构建系统里打印 Makefile 变量
1.1 构建系统 Debug 的第一步：看清变量“真实的模样”
很多人对 Makefile 变量的认知停留在“变量就是赋值后在别处引用”的层面，但 make 的变量系统远没有这么简单。同一个变量名，可能同时存在于环境变量、makefile 内部、命令行参数和系统内置变量中，最后生效的值到底是谁，不是靠肉眼能直接看穿的。
举个例子，项目里明明写了CFLAGS = -g -O2，但你在 shell 环境变量里也设置了CFLAGS，make 在解析时有一套自己的“覆盖逻辑”。在某些情况下，环境变量可能直接盖掉 Makefile 里的定义。结果就是，你辛辛苦苦配的编译参数根本没生效，编译器还是按照另一套参数在干活。这种问题如果不打印，你可能永远想不通为什么行为这么诡异。
再比如，Makefile 里变量名拼写错误、赋值语句前后多了一个空格、递归展开和简单展开语义没分清，都会导致同样的“我以为有值，实际没值”的现象。打印变量是构建系统调试的第一道门，因为它成本最低，反馈最快，能直接告诉你 make 心里到底装着什么。
1.2 打印时机：解析阶段 vs 执行阶段
要真正学会打印，得先理解 make 的两阶段模型。make 在运行时不会一条命令一条命令地“读一行执行一行”，而是先完整读取 Makefile，展开各种变量和函数，构建出整棵依赖关系树，然后再进入执行阶段，按照依赖关系依次运行规则中的命令。
解析阶段和执行阶段的差别，在打印变量时非常关键。比如你写了一个$(info ...)，这属于解析阶段的函数调用，Makefile 读到这里时就会输出。但它输出的变量值，是“读到这一行时”的值，未必是整个文件解析完成之后的最终值。你如果在一个变量后面才给它赋值，那在这个位置打印，打出来的很可能是空值或者旧值。
执行阶段的打印则发生在具体规则执行时，比如在 recipe 里用echo，这时所有变量展开基本都已经完成，打印出来的值会更接近“最终生效值”。所以判断打印结果是真是假，先要搞清楚这句话是在哪个阶段被执行的。
2. 常用打印方法横向对比
2.1 三个内置函数：$(info)、$(warning)、$(error) 的区别
Makefile 里最常用的打印手段就是这三个内置函数，很多教程会混着讲，但它们的定位差异很大，用错场景会带来完全不同的效果。
$(info text)是最温和的打印方式，它只负责输出文本，不中止构建，也不附加任何额外信息，适合日常调试。$(warning text)除了输出文本，还会带上文件名和行号，输出格式类似Makefile:12: warning: text，这在大型项目里非常有用，因为你能立刻知道这条警告是从哪里冒出来的。$(error text)则是在输出后直接终止 make，适合做前置校验，比如某些关键变量没有设置时立刻报错退出。
我平时更推荐在调试阶段先用$(warning)，因为它让你在混乱的构建日志里也能定位到具体位置。$(info)虽然干净，但如果你一条条铺开打印很多变量，日志一长反而分不清谁是谁。
ifndef CROSS_COMPILE $(error CROSS_COMPILE 未设置，请通过命令行传入) endif $(warning 当前平台是 $(shell uname -m))这里$(error)会在变量缺失时直接拦下构建流程，比后面编译器报一团乱码人性化得多。
2.2 在 recipe 里用 echo/printf 打印
执行阶段打印通常是在规则的命令行里加echo。很多新手会在 recipe 里直接写echo "CFLAGS=$(CFLAGS)"，这没问题，但有几个细节需要注意。
首先是每一行 recipe 是独立 shell 执行的。你在一个规则里写两行命令，它们并不像脚本那样共享同一个 shell 会话。打印变量和修改变量、再打印变量是有顺序依赖的，如果你在同一个 recipe 里先export FOO=1再echo $FOO，大概率会失效，因为两行命令分别跑在不同 shell 里。要么用&&连接，要么放在同一行，要么在 Makefile 层面赋值而不要在 shell 层操作。
其次是$符号的处理。Makefile 和 shell 都认识$，make 会先展开$(VAR)，而 shell 则展开$$VAR。如果你确实想打印 shell 层面的环境变量，就得写$$HOME，这样 make 展开后剩下$HOME交给 shell 处理。如果写$(HOME)，make 会先去找自己的内置变量，找不到就展开为空。
all: @echo "使用编译器: $(CC)" @echo "当前用户目录: $$HOME"还有一个小技巧，recipe 命令前面加@，make 就不会先回显这条命令再执行。调试时有时候我倒是不加@，因为那个回显本身就是一种“打印”。一旦变量值需要精确定位，就用printf替代echo，因为 printf 对特殊字符的处理更可预测：
all: @printf "CFLAGS=[%s]\n" '$(CFLAGS)'方括号或者引号包裹值，能让你一眼看出来变量究竟是什么内容，包括那些看不见的头部空格和尾部空格。
2.3 全局打印：make -p 与 print-% 自定义目标
如果你不想在每个规则里都塞 echo，还有两个更系统化的方法。
第一个是用make -p，它会把 make 内部数据库完整打印出来，包括所有变量、规则、文件时间戳等信息。输出量非常庞大，所以一般要配合 grep 用：
make -p 2>/dev/null | grep -E "^(CC|CFLAGS|LDFLAGS) ?="这样能快速看到这些核心变量的实际定义。2>/dev/null是把 stderr 过滤掉，因为 make 有时候会在标准错误里输出一些噪音信息。需要提醒的是，执行make -p时，如果当前 Makefile 有语法错误或者缺少目标，它可能仍然会输出很多内部信息，但这并不能代表构建能正常跑通，你还是要先确保 Makefile 基本可用。
第二个方法是我强烈建议写进通用 Makefile 的“万能打印目标”。在主 Makefile 里加一个模式规则：
print-%: @echo "$* = '$($*)'"然后你就可以随时执行：
make print-CFLAGS make print-CFLAGS print-LDFLAGS这个模式规则的原理很妙。print-%匹配任意一个目标的名称，%捕获的部分会保存在自动变量$*里。如果你执行make print-CC，那么$*就变成CC，后面$($*)相当于“用变量名去查变量值”的动态展开，等于是先把CC这个字符串拿出来，再去查CC对应的值。外层再用单引号包一下，是为了让你看清值的前后有没有空格。
这个print-%目标我实在用了太多次，无论是排查命令行变量覆盖、环境变量污染，还是确认交叉编译器路径，它都是最快的一把尺子。
3. 打印前先搞懂变量类型，否则打印也会骗你
3.1 递归展开变量与简单展开变量
打印变量经常出现一种让人崩溃的情况：变量明明赋值了，打印出来却不是自己想象中的值。这不一定是打印方法错了，而很可能是你选错了变量类型。
Makefile 中的=定义的是递归展开变量。它的特点是“延迟展开”，也就是赋值时不处理右边的内容，到真正被引用时才去展开。:=定义的是简单展开变量，赋值时立刻展开右边内容，类似于命令式编程语言里的一次性求值。
我举个例子：
A := hello B = $(A) A := good这个时候你打印B，得到的是good而不是hello。因为B是递归展开变量，它存储的是“$(A)”这个表达式本身，每次使用时才去查 A 的当前值。如果你把B的定义改成B := $(A)，那 B 在赋值那一瞬间就等于hello，后面 A 再怎么变，都不会影响 B。
这个差异在打印时尤其容易误导人。如果你在 Makefile 末尾打印某个变量，千万不要假设它打印出来的就是你最开始定义时的值。想要“固定住”一份快照，就得用:=。同时也解释了为什么有时候你在 Makefile 中部打印和在末尾打印同一个变量会得到不同结果，这不是 make 疯了，而是展开时机不同。
3.2 命令行变量、环境变量与 override
变量来源的优先级问题，也是打印时必须考虑的。make 的变量优先级大致可以理解为：内置变量最低，环境变量略高，Makefile 内定义更高，命令行参数最高。优先级高的会覆盖优先级低的同名变量。
但这里存在一个容易掉进的坑：make 默认情况下，如果环境变量名和 Makefile 里定义的变量名相同，Makefile 里的定义会优先。可如果你是直接从一个父进程的导出环境里继承了变量，并且 Makefile 里根本没有定义它，那么这个环境变量就会被当作用户级变量引入。所以一个环境变量到底会不会生效，取决于 Makefile 里是否“挡”了这一层。
命令行覆盖则更强势。你执行make CFLAGS="-O2"，哪怕 Makefile 里写了CFLAGS = -g，最后打印 CFLAGS 也会变成-O2。除非你在 Makefile 里用了override CFLAGS = -g强行压制命令行参数。
平时排查时，我会先跑一遍make print-CFLAGS，再用make CFLAGS=test print-CFLAGS看它会不会变，这能很快判断变量是来自命令行还是来自 Makefile。环境变量污染是交叉编译时最隐蔽的问题，尤其是 CI 环境里常常预置了各种工具链路径，你一不打印，根本猜不到源头在哪。
3.3 自动变量和模式规则：打印 $@、$^、$<
自动变量是一类特殊的变量，它们只在具体的规则上下文中有效，代表了目标文件、依赖文件、模式匹配等系统生成的信息。这类变量最值得打印，因为它们的值完全由 make 动态计算，很难靠肉眼预测。
常用的几个自动变量包括：$@表示当前目标名，$^表示所有不重复的依赖列表，$<表示依赖列表中的第一个依赖，$?表示所有比目标新的依赖，$*表示模式规则中%匹配的部分。如果你在编译一个build/foo.o时想知道它到底是基于哪个源文件编译的，打印$<是最直接的。
build/%.o: src/%.c @echo "目标: $@" @echo "源文件: $<" @echo "所有依赖: $^" $(CC) $(CFLAGS) -c $< -o $@打印自动变量时同样要注意位置。你在 recipe 的第一行打印，make 已经帮你计算好了目标文件和依赖列表，所以这些值是可靠的。但如果你在 Makefile 顶层还没有进入任何规则时直接写$(info $@)，那$@是空值，因为自动变量根本没有上下文。
值得一提的是，前文那个print-%目标其实就是在利用自动变量$*，所以理解自动变量的展开机制，不仅提升了打印能力，也让你能写出更灵活的调试目标。
4. 实战场景：嵌入式交叉编译、自动生成 Makefile 与 CMake 对比
4.1 嵌入式交叉编译中打印关键变量（以 rv1106 平台为例）
嵌入式平台的构建，几乎每个新人都要被交叉编译折腾一轮。尤其是像 rv1106 这类 SoC，官方 SDK 往往给出了一大套现成 Makefile 和构建脚本，但环境不同、目录不同、版本不同，构建行为就会千差万别。
这类平台最容易出问题的几个变量是：CROSS_COMPILE、CC、SYSROOT、CFLAGS、LDFLAGS和各类头文件路径变量。很多开发者直接跑make报了一堆 “头文件找不到”，其实是SYSROOT没指对，或者CFLAGS里的-I路径根本没有指向 rv1106 头文件目录。
我的建议是，拿到一个新 SDK，第一件事不是直接执行构建，而是先让它自己“说”两句。可以在 Makefile 末尾加一个专门的调试目标：
debug-env: @echo "CROSS_COMPILE=$(CROSS_COMPILE)" @echo "CC=$(CC)" @echo "SYSROOT=$(SYSROOT)" @echo "CFLAGS=$(CFLAGS)" @echo "LDFLAGS=$(LDFLAGS)" @echo "INCLUDE_DIR=$(INCLUDE_DIR)" @echo "LIBS=$(LIBS)"然后执行：
make debug-env如果打印出来的CC还是gcc，而不是你平台对应的交叉编译器，那后面所有头文件找不到的错误都有了合理解释。嵌入式构建里，打印变量这几秒的功夫，能直接消掉一大半的构建疑难。
4.2 遇到“make: *** 没有指明目标并且找不到 makefile”怎么办
有一个和 Makefile 打印变量相关、又经常被一起提起的报错，就是：
make: *** No targets specified and no makefile found. Stop.中文环境下常见显示为“没有指明目标并且找不到 makefile”。这个报错最常见的含义是：当前目录下没有找到默认命名的 Makefile，同时你也没有给出明确目标。默认命名一般是Makefile、makefile、GNUmakefile，make 只在当前目录寻找这些名字，不会去别处自动翻找。
出现这个报错后，你要先检查文件名。如果项目里的文件叫Makefile.linux，那就要执行make -f Makefile.linux。如果这是一个需要先自动生成的构建系统，比如通过configure或 CMake 生成的 Makefile，那就必须先跑生成步骤，否则目录里的 Makefile 还不存在，自然也谈不上打印变量。
在调试一个非默认位置的 Makefile 时，如果你希望复用前面的print-%目标，可以这样：
make -f /path/to/Makefile print-CFLAGS在找不到 Makefile 的时候，其实你根本还没到“打印变量”这一步，先把文件路径问题理清楚，后面再谈变量的事。
4.3 CMake vs Makefile：打印变量的差异
热门搜索里总有“cmake 和 makefile 区别”，这件事在变量打印的视角下也很有意思。CMake 和 Makefile 虽然都是构建系统，但变量模型完全不同。
Makefile 里打印变量，解析阶段用$(info)，执行阶段用echo，简单直接。CMake 里对应的方法是message()，比如message(STATUS "CFLAGS=${CFLAGS}")。CMake 变量还分普通变量、缓存变量、环境变量，展开时机和持久化方式也不同，复杂程度可以说不降反升。
另外，CMake 生成的 Makefile 是产物，你一执行make，实际跑的是 CMake 根据目标平台生成的规则。这种情况下，如果你发现了诡异行为，与其在生成的 Makefile 里挖，不如回到 CMakeLists.txt 里打印。CMake 的message()虽然帮你把变量输出来了，但要小心它同样有解析顺序问题，中间变量和最终缓存变量经常不是同一个东西。
反过来，如果你手里是一个原生态 Makefile，直接用print-%目标会更顺手。理解这两套工具在变量语义上的差异，能避免你在“两个不同构建系统之间互相抄调试方法”时走弯路。
5. 常见问题排查速查与实操技巧
5.1 打印变量最常见的 6 个坑
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
加了$(info)但没有输出 | 语句根本没被解析，比如写进了注释、或者处于没进入的条件分支 | 检查语法和ifeq分支状态，换一个必然执行的位置打印 |
| 输出是空的，但自己觉得变量有值 | 变量名大小写拼写不一致，或者前后多了一个空格 | 用'$(VAR)'包裹打印，目测值前后空串；检查定义处空格 |
recipe 里 echo 输出还是$(VAR)原样 | 在 recipe 里用了$$或者遗漏转义，make 没展开变量 | make 变量用$(VAR)，shell 变量才用$$VAR |
| 打印值和预期不一致 | 命令行或环境变量在覆盖 Makefile 定义 | 用make -p看变量来源，必要时在 Makefile 里用override |
| 同一个变量在文件不同位置打印结果不同 | 递归展开变量配合了变量赋值顺序 | 确认变量定义用的是=还是:=，在合适时机统一打印 |
make -p输出太大，找不到重点 | 输出包含全部内部数据库 | 配合 grep 过滤，或者定义print-%目标按需打印 |
这六个坑我基本每个都踩过，尤其是 shell 变量和 make 变量的$转义问题，遇到一次就长记性了。打印变量时宁可多写一层引号，也别节省那几行命令，因为变量中的空格、换行、制表符都可能成为后续构建失败的元凶。
5.2 打印之后仍解决不了问题：进阶排查三板斧
如果你已经把变量打印出来了，也确认它们全部符合预期，但构建还是失败，那就说明问题不在变量层面，而在更底层的执行流程里。这种时候我一般会用三板斧。
第一板斧是做最小化复现。把项目拆成一个小场景，比如只编译一个源文件，只用最少的 Makefile 规则，逐步把条件加回去。这个过程能帮你确定是哪一个环节引入了问题。第二板斧是用make -d输出调试信息，它会列出 make 尝试过的每条规则、每次变量展开、每个文件时间戳比较结果，信息量极大，但你寻找的目标聚焦在某一个具体规则上时，它比-p更有指向性。第三板斧是跟踪目录和工具链，打印变量只证明了“变量已经正确”，可真正的构建却可能因为某个头文件目录下根本不存在对应文件而失败，这种问题不取决于变量值，而取决于文件系统。
在嵌入式场景里，我常常发现变量打印正确，但实际编译器路径下没有可执行文件，或者 sysroot 目录下缺少某个库的链接文件。这种时候不要继续死磕 Makefile，该去看文件、看工具链版本，甚至重新解压 SDK。打印变量是定位问题的开始，不是终点。
说回我自己，那些年帮我解决最多问题的，其实就是一个放在通用 Makefile 里的print-%目标。它让我在遇到复杂构建问题时能够很快把变量值从一团乱麻里抽出来，而不是靠猜。打印变量这件事，说白了就是给构建系统装上仪表盘。仪表盘的数据未必能让问题立刻消失，却能让你知道车跑偏的方向到底朝哪。你下一次再遇到头文件路径不对、编译选项诡异、交叉编译器失效的时候，不妨先停下来，把CC、CFLAGS、SYSROOT这几个“仪表盘读数”打出来，我打赌你会少掉很多头发。
