企业官网建设流程全解析

在GNU Make的世界里，命令行参数是构建系统的入口控制界面。你可能经常敲这样的命令：

make clean all make DEBUG=1 V=1 -j8 make -C build install PREFIX=/usr/local

但多数人只停留在“能用”的阶段，并不清楚这些参数在make进程内部究竟走了怎样的路径：哪些变量会覆盖Makefile里的赋值，哪些参数会被自动带到子make，为什么明明写了CFLAGS += -g却始终不生效，为什么子目录的make总是收不到你传入的变量。这篇文章把这些细节一次讲透，适合正在用Makefile管理中小型C/C++项目的开发者，也适合想把手动编译命令固化成可复用脚本的人。

GNU make的官方手册其实写得很全，但手册是工具书，不会告诉你哪些坑最常见。这篇文章是我在实际工程里用过很多次之后的经验总结：命令行参数分类、变量优先级博弈、递归make的传参链路、debug/release切换的标准写法，以及一堆让人抓狂的疑难问题，都理清楚。

1. 命令行参数的本质：GNU make在你敲下命令的那一刻做了什么

1.1 命令行参数的三类角色：目标、变量和选项

GNU make命令行的参数其实分三类，很多人混在一起用，所以容易困惑。第一类是目标（goal），比如make clean里的clean，它告诉make要构建什么；第二类是变量赋值，比如make DEBUG=1里的DEBUG=1，它直接往make的变量环境里注入一个值；第三类是选项，比如-j8、-C src、-f MyMakefile，用来控制make自身的执行方式和行为。

它们三者的解析顺序是：make先解析选项，再构建目标列表，同时收集所有命令行变量赋值。这中间有一个很多人忽略的细节：目标其实是可以有多个的，make clean all会先执行clean再执行all，这就是常见的“先清理后构建”组合命令的底层原理。而变量赋值则从左到右依次生效，后面的赋值会覆盖前面的，make FOO=1 FOO=2最终FOO的值是2。

选项里最常用的是-C（切入目录执行）、-f（指定makefile文件）、-j（并行任务数）、-n（只打印命令不执行）、-B（强制重新构建）这几个。它们会写进make内部的MAKEFLAGS变量中，后续子进程执行时，make会自动把MAKEFLAGS传递下去，这正是递归make中很多参数“不请自来”的原因。

1.2 make查找makefile的顺序之争

当你在命令行不指定-f时，make会按顺序去找GNUmakefile、makefile、Makefile三个文件，找到哪个用哪个。有个细节值得注意：GNUmakefile的优先级最高，但它只在Linux/Unix环境下才被默认识别，一些跨平台工程为了兼容性，刻意不用这个名字。makefile和Makefile的区别仅仅是大小写，按照手册的说明，如果三个文件同时存在，make会优先使用GNUmakefile，然后makefile，最后才轮到Makefile，这与很多人的直觉相反，因为多数项目习惯用Makefile。

实际工程里，绝大多数人固定用Makefile这个文件名，这没问题。但如果你在一个既有makefile又有Makefile的目录里执行make，却没有意识到寻找顺序，就会发生“make明明跑的是另一个文件”的乌龙。排查这种问题，最快的方式就是用make -p打印当前make的数据库信息，或者直接make -f指定绝对路径，绕开所有搜索逻辑。

命令行参数在makefile文件被读取之前就已经被解析完成，这个顺序非常重要。意味着Makefile内部用ifeq ($(DEBUG),1)这类条件判断时，能够直接读取到命令行传进来的变量值。相反，如果你试图在Makefile里通过$(shell echo $@)之类的写法去获取“当前命令行传了哪些目标”，就会受到限制，因为目标列表不在普通变量的读取通道里。

1.3 MAKEFLAGS：命令行参数传递的隐形载体

GNU make有一个内置变量叫MAKEFLAGS，它存放了当前make进程的所有命令行选项。默认情况下，make -j8执行后，MAKEFLAGS的值包含j8；make -C src执行后，包含C src（带空格时会有引号处理）。这个变量会自动导出到环境变量中，传递给子make进程。

这意味着你不需要手动用export MAKEFLAGS去传递选项，make在内部已经完成了传递。make -j8在顶层执行时，所有被调用的子make都会继承-j8，除非在Makefile里显式地unexport MAKEFLAGS，不过这几乎没人会做。理解了这一点，很多“为什么我的子Makefile收到了奇怪的参数”类问题就迎刃而解了。

2. 变量传递的优先级博弈：命令行变量与Makefile内赋值的关系

2.1 四种赋值方式与命令行变量的优先级

Makefile内部给变量赋值有四种语法：=（递归展开）、:=（简单展开）、?=（条件赋值）、+=（追加赋值）。它们的差异是GNU make学习中的一个经典难点，但我在这里想强调的重点是优先级：命令行变量赋值在make读取Makefile之前就已经进入变量数据库，并且拥有最高的优先级，高于普通赋值，低于override指令。

用代码说明：

# Makefile CFLAGS = -O2 DEBUG ?= 0

命令行执行make CFLAGS="-O0 -g"时，Makefile里的CFLAGS = -O2不会覆盖命令行值，最终CFLAGS是-O0 -g。这是最基础的规则，很多人都知道，但实际工程里导致困惑的往往是组合场景。

?=是条件赋值，只有当变量尚未定义时才赋值。如果变量在命令行中已经定义，?=直接跳过。所以DEBUG ?= 0配合make DEBUG=1可以让你在不修改Makefile的情况下切换默认值，这是很实用的写法。但是反过来，如果命令行传了DEBUG=（赋空值），?=也会认为变量已定义，不会重新赋值。

:=和+=受命令行变量优先级影响的方式不同。+=在变量已定义时追加值，但如果变量在命令行里定义过，Makefile里执行CFLAGS += -Wall其实不会追加到命令行值的尾部，而是创建一个名为CFLAGS的新实例吗？这里需要澄清：实际上make对命令行变量有特殊处理，Makefile中用+=操作一个来自命令行的变量时，系统会认为这个变量具有“来自命令行的来源”，追加操作不会生效，除非先override。

2.2 override指令：命令行变量不可覆盖的唯一例外

语法：override VARIABLE = value或override VARIABLE += value。它的作用是：即使变量通过命令行赋值，Makefile中的override赋值也拥有最终决定权。

实际场景：假设你的Makefile统一管理编译选项，但又允许用户通过命令行传入额外的CFLAGS：

# 强制加入-Wall，无论命令行传什么都不会被覆盖 override CFLAGS += -Wall

这个技巧在控制编译行为时很有用。比如一个跨平台工程，Makefile里需要给不同平台追加不同的宏定义，又不想让用户在命令行误传平台宏导致混乱，那么override DEFINES += -D__YOUR_PLATFORM__就能锁死。

但override的使用要克制。滥用它会让命令行参数完全失去意义，导致使用Makefile的人感到困惑：明明传了CC=clang，最终用的还是gcc，因为Makefile里写了override CC = gcc。我见过的工程里，override最常见的用途是强制追加默认警告选项和必要的特性宏，而不是去覆盖用户显式指定的参数。

2.3 环境变量、make -e与命令行变量：谁说了算

环境变量对make构建的影响是一个很少被系统讲解但实际踩坑极多的点。make启动时会读取当前shell的环境变量，把它们作为变量放入make自己的数据库中。普通赋值规则下，Makefile里的CC = gcc会覆盖环境变量CC，但如果没有这个赋值，make会直接用环境变量里的CC。

优先级从高到低排列如下：

默认情况下，环境变量会被Makefile内赋值覆盖，也就是说Makefile里一旦写了CFLAGS = -O2，你在shell里设了CFLAGS=-g也不会生效。如果想改变这个规则，可以让make在环境变量和Makefile赋值冲突时偏向前者，那就是make -e选项。-e会让环境变量拥有超过Makefile内赋值的优先级，但依然低于命令行变量的优先级。

实际操作中我发现，make -e是一个双刃剑。它能让你用一个统一的shell环境变量去驱动多个Makefile工程，不用去改动每个工程的Makefile文件。但也会带来“本地能编译，服务器上编译失败”的诡异问题，因为服务器环境变量和本机不同。我更推荐的做法是：不要在Makefile里留太多的隐式变量依赖，把需要用到的配置项统一通过命令行参数或?=默认值设计，而不是依赖环境变量。

2.4 命令行变量与函数、条件判断的联动时机

Makefile是边读取边执行的语言，变量展开和条件判断发生在make读取Makefile的阶段，而不是命令执行阶段。所以命令行变量在Makefile被读取之前就已经进入变量数据库，这意味着ifeq能正确读取。

举个例子：

# config.mk ifeq ($(BUILD_TYPE),release) CFLAGS += -O3 -DNDEBUG else CFLAGS += -O0 -g endif

命令行执行make BUILD_TYPE=release，ifeq能正确读取到了release。这个特性是所有“一个Makefile适应多种配置”方案的基础。但需要注意：$(shell ...)函数在Makefile解析阶段执行，此时命令行变量也已经可用。如果你在Makefile里写了：

ARCH := $(shell gcc -dumpmachine | cut -d- -f1)

这个ARCH变量不依赖命令行参数，但如果想让它变成可选参数，就需要重新设计：

ARCH ?= $(shell gcc -dumpmachine | cut -d- -f1)

这样用户执行make ARCH=arm64时，命令行的ARCH会覆盖自动检测结果。

3. 向子make和多目录工程传递参数

3.1 递归make时参数的自动传递链路

在项目规模变大后，总量大的工程通常把不同模块放在不同子目录，每个子目录有自己的Makefile，由顶层的Makefile递归调用。这样的结构下，命令行参数的传递就成为必须理清的话题。

GNU make递归调用的标准写法是在Makefile里写：

subdir: $(MAKE) -C src

注意这里必须用$(MAKE)而不是make。区别在于：$(MAKE)在Makefile中被特殊处理，make会把自己命令行的参数、MAKEFLAGS变量以及命令行中定义的变量，一并传给子make进程。如果你图省事直接写了make，子make收到的就是一个“干净的”make进程，命令行参数一概丢失。

命令行传递的完整链路是：用户执行make FOO=bar -j4，顶层make把FOO=bar和j4写进MAKEFLAGS，同时把FOO=bar作为环境变量导出到子make进程。子make在启动时解析MAKEFLAGS和这些环境变量，从而准确地“复现”父make的命令行状态。

3.2 用export显式传递变量

手动指定的命令行变量会被自动导出到子进程，但Makefile中的普通变量默认不会导出到子make。想让一个变量被子make继承，可以在顶层Makefile中显式声明：

export BUILD_ROOT := $(shell pwd)

这样BUILD_ROOT会作为环境变量传递给所有子make进程，子make里就可以用$(BUILD_ROOT)来拼接相对路径。这个方式对传递路径信息非常有用，尤其是在子目录里编译时需要知道工程根目录的场景。

另一个场景是传递配置变量，比如：

# 顶层 Makefile EXPORT_FLAGS = RELEASE=1 export RELEASE

或者在Makefile中直接：export RELEASE := 1。子make中可以用$(RELEASE)读取到1。这里有个容易混淆的点：export只是把变量放进环境，子make是作为环境变量读取，遵循环境变量的优先级（低于Makefile赋值）。如果子Makefile里写了RELEASE = 0，那么子make最终用的是0，父make传进来的1只作为环境变量存在，被Makefile赋值覆盖了。

3.3 MAKEFLAGS与MAKEOVERRIDES两个特殊变量的区别

MAKEFLAGS和MAKEOVERRIDES是两个极其相似但功能不同的特殊变量。MAKEFLAGS包含所有命令行选项，比如-j4、-C src、--no-print-directory；而MAKEOVERRIDES只包含命令行定义的变量赋值，比如FOO=bar。

子make进程会同时读取这两个变量。读取MAKEFLAGS是为了继承选项行为；读取MAKEOVERRIDES是为了重新定义命令行变量（让变量在子make中也拥有命令行优先级）。

有时候你会看到网上有人建议清空MAKEOVERRIDES来阻止参数递归传递：

MAKEOVERRIDES =

但这个做法往往导致子make出现更隐蔽的问题，我不推荐。

3.4 make -C与相对路径的坑

make -C dir本质上等价于cd dir && make，它在切换工作目录后执行make。但是这里面有一个很经典的坑：-C切换目录后，MAKEFLAGS里会记录这个选项，所以顶层Makefile里如果又使用$(MAKE) -C subdir，会有多重切换的效果。更麻烦的是，如果在Makefile里写了依赖相对路径：

SUBDIR = lib $(MAKE) -C $(SUBDIR) # 这行命令在子make中执行时的工作目录是lib # 之后再嵌套$(MAKE) -C ..，又切回去了

实际工程中如果要跨目录构建，我习惯在绝对路径上构建，或者用$(CURDIR)来重新拼接路径。

举一个常见的坑：你的项目根目录是/home/user/proj，顶层Makefile里写了：

all: cd lib && $(MAKE)

这个写法在命令行执行make -C /home/user/proj时，进入Makefile后的当前目录是/home/user/proj，然后cd lib正常。但如果用户直接在顶层目录以外执行make -C /home/user/proj/lib，那就直接切到lib目录执行lib下的Makefile，逻辑完全不一样。这是-C造成的“工作目录漂移”问题，真正稳妥的方式是：用$(MAKE) -C $(ROOT_DIR)/lib，其中ROOT_DIR在顶层Makefile中用$(shell pwd)提前固定下来。

3.5 多目录源码编译中参数传递的设计建议

遇到多目录源码编译时，很多新人会把参数全部写进顶层Makefile，再用export往子目录铺。这会导致“变量爆炸”：层次多了以后，全局变量满天飞，调试一个变量从哪传入要翻遍所有Makefile。

更可维护的做法是：把可能需要调整的配置项集中到一个单独文件，比如config.mk，顶层Makefile里include config.mk，子目录Makefile里也需要include ../config.mk（用相对路径）。这样命令行传入的参数只需要在顶层指定，config.mk里的默认值保证子目录也能读到：

# config.mk PLATFORM ?= linux TOOLCHAIN_PREFIX ?= arm-none-eabi- CC := $(TOOLCHAIN_PREFIX)gcc

然后在每个子Makefile里：

include $(ROOT_DIR)/config.mk

同时ROOT_DIR在顶层用一个export ROOT_DIR := $(shell pwd)导出。这套组合拳是我在几个项目里验证过的最佳实践：变量默认值在config.mk里定义，顶层和子目录统一include，命令行传入参数通过?=保证未被覆盖时使用默认值。可读性和扩展性都比把几十个export堆在顶层强得多。

4. 典型场景实战：用命令行参数控制构建配置

4.1 Debug与Release切换的标准写法

命令行参数最有价值的应用场景之一，就是让同一份Makefile在Debug和Release之间一键切换。这里要特别注意优先级细节，否则会写出“切换无效”的Makefile。

推荐写法：

# config.mk BUILD ?= debug ifeq ($(BUILD),release) CFLAGS ?= -O3 -DNDEBUG else CFLAGS ?= -O0 -g endif

命令行执行make BUILD=release，ifeq读取到release分支；执行make BUILD=debug，进入debug分支。因为用了?=，Makefile里的CFLAGS只有在命令行没有显式赋值时才生效。

这里有一个很多人会踩的坑：如果把CFLAGS ?=和ifeq的顺序写反：

CFLAGS ?= -O0 -g ifeq ($(BUILD),release) CFLAGS ?= -O3 -DNDEBUG # 此时CFLAGS已经赋值，永远不会走到这里 endif

最终release配置也不会得到-O3。所以条件赋值必须在任何可能触发变量初始化的代码之前完成，这是Makefile的一个顺序敏感点。

4.2 向编译器和链接器传递参数

命令行参数不仅用来控制Makefile自身逻辑，更多时候是直接传给编译器和链接器。一个常见的需求是给某个文件单独添加宏，或调整警告等级：

make CFLAGS="-Wall -Wextra -Werror" LDFLAGS="-static -s"

或者指定编译器：

make CC=clang

GNU make内置了很多隐式规则变量，比如CC用于C编译器，CXX用于C++编译器。命令行传make CC=clang会覆盖Makefile里的CC ?= gcc，最终隐式规则中执行的是clang。

有一个非常隐蔽的坑：如果你在Makefile中直接写命令而不是依赖隐式规则：

%.o: %.c gcc -c $< -o $@

那命令行传CC就毫无意义，因为命令写死了gcc。推荐写法是用变量代替具体命令：

%.o: %.c $(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@

这样CC、CFLAGS等才能通过命令行赋值或环境变量来覆盖。这是我在审查别人的Makefile时最常指出的一点：显式规则里硬编码编译器，等于堵死了参数传递的路。

4.3 带空格和特殊字符的参数传递

命令行参数里有空格是个让人头疼的问题。比如：

make CFLAGS="-O2 -g -DDEBUG"

在shell里加引号传参，make收到的是一整个字符串-O2 -g -DDEBUG。Makefile里展开时，它会按空格拆分成多个词传递给shell命令，所以最终命令行里会出现gcc -O2 -g -DDEBUG -c foo.c，这种行为符合直觉。但如果想让一个变量的值本身就包含空格，并且在命令行中作为单一值传递：

make "MSGS=hello world"

Makefile里$(MSGS)展开成hello world，如果用在shell命令的赋值场景会出问题，比如：

test: echo $(MSGS)

展开后变成echo hello world，会打印两个词。如果想让它按照一个字符串处理，需要加引号：

test: echo "$(MSGS)"

shell命令中细节很多。另一个容易掉进去的坑是特殊字符传递（尤其是括号、分号、反斜杠），shell元字符会被Shell解释，导致Makefile里的命令行为异常。比如：

make FOO="a; rm -rf /"

执行时如果Makefile里写了echo $(FOO)，分号会被Shell解释为命令分割符，那就非常危险。防御措施是：除非绝对信任输入，否则所有外部传入变量在传入Shell命令时用引号包裹。

4.4 命令行参数配合条件判断和函数的进阶玩法

命令行参数还能和GNU make的函数库联动，实现更灵活的构建配置。比如用$(filter ...)函数判断命令行传入了哪些变量，或检查是否处于clean模式：

ifeq ($(filter clean,$(MAKECMDGOALS)),clean) $(info 当前目标包含clean) endif

MAKECMDGOALS是另一个内置变量，保存了命令行传入的所有目标名。通过与$(filter ...)配合，你可以在构建前自定义一堆联动逻辑，比如clean时自动清理临时目录。

再举一个进阶例子：想要根据命令行变量自动产生编译选项。

ENABLE_FEATURE ?= 0 ifeq ($(ENABLE_FEATURE),1) override CFLAGS += -DENABLE_FEATURE endif

这样make ENABLE_FEATURE=1编译时自动追加宏定义。叠加之前提到的override和+=，我们可以构建一个比较成熟的可配置编译框架。

5. 常见问题与排查技巧实录

5.1 报错“make没有指明目标并且找不到makefile”

这是网上搜得非常多的一个报错，通常出现在你直接执行make但当前目录没有makefile，或者Makefile文件名不对的时候。排查过程很简单：先ls确认是否有Makefile或makefile，如果都没有，那就要检查是不是进入错了目录。

如果文件名正确但依然报错，就要看文件是否有执行权限和读取权限。我遇到过一个很罕见的情况：用户从Windows拷贝了一个Makefile到Linux，文件名末尾带了看不见的CRLF换行符，ls的时候显示正常，但make用文件名匹配时失败。解决办法是file Makefile看编码，然后用sed -i 's/\r$//' Makefile去掉回车符。

还有个更隐蔽的场景：在空目录里直接执行make -f /path/to/Makefile，但Makefile内部有include指令，引用了当前工作目录下的文件。由于工作目录不对，include的文件找不到，报的却是“没有指明目标”而不是“找不到文件”。这就要靠make --debug=v或者make -n逐步查看解析过程。

5.2 子make收不到变量

子make收不到父make里的变量，最常见原因是父Makefile里没有使用export，而子make读取的是环境变量。很多人以为在父Makefile里定义变量后，子make就能自动继承，其实不然。GNU make只会传递命令行参数、MAKEFLAGS和显式export的变量给子进程。普通变量默认就是局部于当前make进程的。

还有一种情况是export写在规则中而不是顶层：

all: export FOO=bar $(MAKE) -C sub

由于make是在一个shell中逐行执行命令的，export FOO=bar只在当前shell生效，但$(MAKE)实际上是启动了一个新的shell环境，新的shell不会继承这条export，子make最终依然收不到。正确的做法是把export提到Makefile顶层位置：

export FOO := bar

或者在命令行中传变量：

all: $(MAKE) -C sub FOO=bar

5.3 变量在Makefile中赋值后仍被命令行覆盖

有用户反馈：在Makefile里明确写了CFLAGS = -O2，但命令行执行make CFLAGS="-O0 -g"后，Makefile里的赋值不生效。这其实不是bug，而是GNU make的设计规则。命令行变量拥有最高优先级（除override外）。要想不被命令行覆盖，只有两个办法：一是用override CFLAGS += ...，二是不要在命令行传该变量。如果Makefile里想保留一个不可被覆盖的“底线值”，完全可以用override CFLAGS += -Wall这类写法。

但也要警惕另一种情况：Makefile里用了=递归展开，变量的赋值引用了其他变量，导致展开后的值比预期的晚一步。比如：

CFLAGS = -O2 CFLAGS += $(DEBUG_CFLAGS) # 命令行传 DEBUG_CFLAGS="-g" make DEBUG_CFLAGS="-g"

需要注意：+=对命令行变量行为的限制，如果DEBUG_CFLAGS也在命令行传入，Makefile里的+=未必能追加成功，需要结合override。这就是为什么统一管理变量的config.mk方案，要配合?=和override来设计，避免命令行变量和内部变量之间互相“打架”。

5.4 参数值被截断或路径分隔符问题

命令行参数值如果含空格，在shell里必须加引号，否则shell会把空格视为不同参数。但在Makefile内部，变量展开之后的空格处理同样复杂。比如你想传递一个路径列表：

make INCLUDES="-I./src -I./include"

Makefile里如果写：

all: gcc $(INCLUDES) -c main.c

展开后是gcc -I./src -I./include -c main.c，行为正确。但如果命令行传的值里包含反斜杠，在Windows环境下就麻烦了。比如：

make LIB_PATH="C:\libs\foo"

Makefile里写：

$(LIB_PATH)

由于反斜杠在Makefile中通常只是普通字符，传给shell后却可能被当成转义符。在Windows下使用MinGW/MSYS环境时，路径中最好统一使用正斜杠（C:/libs/foo）来避免这类麻烦。

5.5 GNU Make在Windows与类Unix环境下的行为差异

如果你在Windows用Makefile（比如安装Minimalist GNU for Windows或者MSYS2），会碰到一些独有的问题。最常见的是路径分隔符：命令行里写make -C src在Windows命令行中同样可用，但如果路径含反斜杠，建议改为正斜杠形式再传入。Makefile里的$(shell pwd)在纯Windows的cmd环境下可能失败，因为pwd是Unix命令。在MSYS2或Git Bash里则正常。

另一个点是换行符和字符编码。从Windows编辑的Makefile到Linux下跑，用CRLF会导致include和规则解析异常。反过来，在Windows下写的Makefile也可能出现UTF-8 BOM头，make不识别BOM，在文件开头会有非法字符。用文本编辑器把文件转为UTF-8无BOM格式，并统一LF换行，能避开90%的跨平台Makefile问题。

还要留意：Windows的cmd下，命令行传FOO=a b时引号的处理方式与Bash不一样。cmd对引号的支持更弱，传值经常被截断，我遇到这样的问题会改用MSYS2的bash环境执行make，或者在Makefile里用?=默认值来减小传参复杂度。

5.6 使用make --debug排查问题

排查命令行参数问题，make --debug=v是我最常用的工具。它会打印make解析文件、变量展开、规则匹配和命令执行的详细过程。想快速看变量值，用make -p可以打印整个make的变量数据库。

一个实用的调试技巧：在Makefile里用$(info VAR=$(VAR))输出变量当前值。因为Makefile是边读边执行的，$(info ...)在解析阶段就会打印，能帮你确认命令行变量是什么时候进入变量数据库的。注意别用echo $(VAR)，因为规则里的命令要等匹配目标执行才运行，调试起来节奏更慢。

一些经验之谈

我做过不少需要跨平台、跨目录构建的项目，过程中的体会是：命令行参数的使用并不是技巧越多越好，而是要建立一个清晰的约定。我的习惯是：所有可以被调整的配置统一走config.mk，用?=定义默认值；必须由命令行强覆盖的变量单独列出来，在config.mk里统一用override锁死；子目录统一include同一个config.mk；$(MAKE)和export严格按照需要显式使用，不依赖隐式行为。

最后分享一个小技巧：在命令行变量里加一个V=1的开关，控制是否打印详细编译命令。典型的写法是：

ifeq ($(V),1) Q = else Q = @ endif

然后在每条规则前加$(Q)：

%.o: %.c $(Q)$(CC) $(CFLAGS) -c $< -o $@

这样默认安静构建，出问题时通过make V=1看到完整命令。我几乎在每个项目里都用这套方案，排查编译问题省了很多时间。命令行参数看着简单，但每一条都值得用清楚了再上工程。