我先讲一个自己踩过的坑。有一回调试一块嵌入式板卡交叉编译老是找不到头文件我在网上翻了好几圈帖子最后才发现其实是 Makefile 里的头文件路径变量被环境变量静默覆盖了。当时要是早点把变量打出来大概十分钟就能定位问题结果白折腾了半天。从那以后我养成了一个习惯遇到任何构建问题第一件事不是翻文档而是先把变量打印出来。Makefile 里打印变量这个需求看起来再简单不过但真正操作起来里面还是有不少细节值得掰扯。你可能会想不就是echo一下吗实际上 Makefile 的变量展开有解析阶段和执行阶段之分变量来源也分命令行、环境变量、内部定义好几类打印方法和时机一旦选错打出来的东西只会误导你。这篇就把 Makefile 打印变量的方法、原理、坑和实战挨个过一遍适合刚入门的开发者也适合在嵌入式交叉编译场景里折腾的老手看看。1. 为什么要在构建系统里打印 Makefile 变量1.1 构建系统 Debug 的第一步看清变量“真实的模样”很多人对 Makefile 变量的认知停留在“变量就是赋值后在别处引用”的层面但 make 的变量系统远没有这么简单。同一个变量名可能同时存在于环境变量、makefile 内部、命令行参数和系统内置变量中最后生效的值到底是谁不是靠肉眼能直接看穿的。举个例子项目里明明写了CFLAGS -g -O2但你在 shell 环境变量里也设置了CFLAGSmake 在解析时有一套自己的“覆盖逻辑”。在某些情况下环境变量可能直接盖掉 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 FOO1再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 CFLAGStest 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、GNUmakefilemake 只在当前目录寻找这些名字不会去别处自动翻找。出现这个报错后你要先检查文件名。如果项目里的文件叫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这几个“仪表盘读数”打出来我打赌你会少掉很多头发。