Makefile字符串函数实战：patsubst、filter、strip全解析

最近在梳理 Makefile 的整个函数体系，写到字符串处理这块时发现，这其实才是 Makefile 的“隐藏主线”。你别看平时写规则、写变量定义好像挺简单，一旦工程里源码文件数量超过 20 个，靠手写列表绝对是一场灾难。我见过不少同学把几十个 .c 文件名一个一个列在变量里，然后复制粘贴改后缀，扩展性为零，改一个文件名都心惊胆战。而 patsubst、filter、strip 这一族字符串函数，就是专门解决这类问题的：自动化生成目标文件列表、按模式筛选文件、清理变量里的多余空格。这篇是“Makefile 专家之路 | 函数篇”的第八篇，我们不玩虚的，直接把每个函数的语法、行为、坑、实战组合一次说透，适合刚接触函数的新手，也适合已经写过一段时间 Makefile、想系统查漏补缺的人。

1. Makefile里的字符串函数到底解决什么问题

1.1 Makefile变量的本质：一个被空格分隔的字符串世界

想要理解字符串函数为什么在 Makefile 里这么重要，首先得接受一个事实：Makefile 中的变量本质上就是字符串，而列表变量就是“用空格分隔的多个字符串”。比如：

SRCS := main.c utils.c protocol.c device.c

这看起来像是一个“数组”，实际上它只是一个字符串"main.c utils.c protocol.c device.c"。Makefile 本身并没有数组类型，规则里的依赖、命令、目标，全都靠文本展开来工作。构建系统要做的核心转换，无非就是“把一组 .c 文件名变成一组 .o 文件名”“从编译选项里挑出某几个参数”“判断某个字符串是否存在”这类文本操作。

字符串函数的价值就在这里：它们是 Makefile 里唯一的“数据加工工具”。没有它们，你只能手工维护所有列表；有了它们，你可以用一条规则从源文件列表推导出目标文件列表，工程从几个文件扩展到几百个文件，Makefile 本体几乎不用动。这也是我特别推荐大家在写工程构建脚本时“函数优先”的原因：变量定义得再漂亮，不会转换，最后还是得手写。

1.2 先建立选型思维：这四个动作覆盖了九成需求

字符串函数有好几个，初次接触容易记混，但你只要抓住“动作”这个维度，就非常好选型。我习惯把字符串处理需求归结为四类：

• 替换：把.c变为.o，把路径前缀src/换成build/，这类操作用patsubst，如果只是无模式的固定字符串替换，用subst。
• 筛选：从一个列表里挑出符合某类模式的部分，或者剔除某类模式，分别对应filter和filter-out。
• 清理：去掉变量首尾多余空格、压缩连续空格，用strip；去重加排序，用sort。
• 查询：判断某个字符串是否包含在另一个字符串里、统计单词个数、取某个位置的单词，分别用findstring、words、word。

把这四个动作想清楚，再遇到任何变量处理需求，你都能第一时间知道该查哪个函数，而不是翻文档。后面几节我会逐个拆开讲。

1.3 函数总览表：先收藏再细读

为了让你有个整体地图，我把本篇涉及的核心函数先列出来。这张表建议直接收藏，后面写 Makefile 忘了参数时回来扫一眼。

2. 核心函数逐一拆解：语法、行为与隐藏细节

2.1 patsubst：你每天都在用，但这3个细节最容易踩坑

patsubst是模式替换函数，全称是 pattern substitution，语法如下：

$(patsubst pattern,replacement,text)

它在text这个空格分隔的单词列表里，把符合pattern的单词替换成replacement。pattern里的%表示“匹配任意非空字符串”，replacement里的%会被替换成实际匹配到的内容。

最经典的用法，就是把.c源文件列表变成.o目标文件列表：

SRCS := main.c utils.c protocol.c OBJS := $(patsubst %.c,%.o,$(SRCS))

展开后 OBJS 就是main.o utils.o protocol.o。这条代码几乎是所有多文件工程的基石。

但这里必须强调一个很多人都会踩的坑：pattern里如果有多个%，只有第一个%被当作通配符，其他%都只是普通字符。什么意思？比如：

TEXT := /home/user/main.c RESULT := $(patsubst /home/%/%.c,/tmp/%/%.o,$(TEXT))

你以为这个能匹配两层目录，实际上第二个%就是字面量%，根本匹配不到main.c这个单词，结果原样返回。正确的做法是pattern里只保留一个真正的%，其余部分写完整。这也是patsubst和直接写subst的一个关键差异：subst是固定文本替换，patsubst是模式驱动替换，两者语义完全不同。

还有一个细节容易被忽略：text里的单词必须“整体匹配”模式才替换。比如SRCS := app_main.c，你用$(patsubst %.c,%.o,$(SRCS))能替换；但如果你写$(patsubst main%.c,xxx%.o,$(SRCS))，因为单词不是以main开头，它也不会匹配。记住这个“整体匹配”规则，排查问题时会省很多时间。

注意：patsubst里replacement的%只对应pattern中第一个%捕获的内容。还有一个等价写法：在变量名前加:后缀替换，例如$(SRCS:.c=.o)，这实际就是固定后缀替换的简写，能力弱于patsubst，只适合干简单活。

2.2 filter / filter-out：按模式筛选字符串列表的利器

filter的作用是保留列表中“符合任一模式”的单词，filter-out则相反，剔除符合模式的单词。语法都是：

$(filter pattern1 pattern2...,text) $(filter-out pattern1 pattern2...,text)

注意这里的pattern参数同样支持%通配符，并且多个模式之间用空格分隔。最常见的需求是把源文件列表里的.c和.h分开：

FILES := main.c utils.h protocol.c device.h C_SRCS := $(filter %.c,$(FILES)) H_HEADERS := $(filter %.h,$(FILES))

展开后C_SRCS是main.c protocol.c，H_HEADERS是utils.h device.h。这个筛选逻辑非常直观，但它隐藏着一个关键陷阱：filter是按空格分隔的“单词”做模式匹配，不是子串匹配。比如：

VERSION := debug_v1.0 RESULT := $(filter %debug%,$(VERSION))

你会以为能匹配到，实际上整个变量只有一个单词debug_v1.0，模式%debug%确实匹配它，但如果你想从一行文本CFLAGS += -g -O2 -DDEBUG里筛出-DDEBUG，用$(filter -DDEBUG,$(CFLAGS))是可以的，因为它按单词匹配；用$(filter DEBUG,$(CFLAGS))就不行，因为没有一个单词是纯DEBUG，-DDEBUG是一个整体单词。如果你只想判断是否出现某个子串，应该用findstring，而不是filter。

filter-out我常在两个地方用：一个是从链接源文件里排除测试文件，比如filter-out %_test.c；另一个是从编译选项里去掉某个不该出现的参数。它的行为完全对称，不需要额外记忆。

2.3 strip：空格清理与变量比较的“隐形守卫”

strip单独看起来太简单，很多教程一笔带过，但实际它是排查问题的关键角色。语法：

$(strip string)

作用是把输入字符串的首尾空格去掉，并把单词之间连续的多个空格压缩成单个空格。举个例子：

TEXT := " -g -O2 -Wall " CLEANED := $(strip $(TEXT))

展开后结果是-g -O2 -Wall。看起来就是一个“整理格式”的函数，对吧？但它的真正价值在于：Makefile 里变量比较是非常脆弱的行为，而多余空格往往是逻辑错误的罪魁祸首。

比如你有这样一个判断：

ifeq ($(CFLAGS),-g)

如果CFLAGS定义是CFLAGS := -g，末尾多了一个空格，那么两个字符串比较就不相等，ifeq直接走进else分支，表现就是“明明设置了 -g，却走了非调试分支”。把第一个参数包一层$(strip ...)就能稳定解决：

ifeq ($(strip $(CFLAGS)),-g)

这是我能想到最典型的“strip 救场”场景。另外一个使用场景是清理用户输入的环境变量。你自己写的变量还好控制，但外部传入的EXTRA_CFLAGS这类变量，经常带着换行、全角空格、连续空格一类问题，统一过一遍strip再往下传递，能省掉大量诡异的编译问题。

还有一个容易被忽略的细节：strip不会删除单词内部的空格，它只处理首尾和连续空白。比如"hello world "会变成hello world，但"he llo"不会变成hello，这一点要分清。

2.4 辅助函数快速盘点：subst、findstring、sort、word

除了上述三个“主角”，还有几个辅助函数我也经常用到，这里统一过一遍。

subst是固定字符串替换，语法$(subst from,to,text)，把所有出现的from都替换成to。from里不支持%通配，它做的是纯字面替换。比如：

NAME := app_demo UPPER_NAME := $(subst demo,release,$(NAME))

结果是app_release。它和patsubst的关系很像“查找替换”与“模式匹配”的关系，能不能用subst解决的问题，优先用subst，因为更简单、可读性更高。

findstring用来判断“某个子串是否包含在某个字符串中”，语法$(findstring find,in)。如果找到了，返回find本身；找不到，返回空字符串。它和filter最大的区别就是不做单词边界限制。我在 Makefile 里最常用它判断编译选项：

ifneq ($(findstring -g,$(CFLAGS)),) $(warning debug flags present) endif

这个写法比filter更宽容，因为-g不管出现在哪个单词里都能被捕捉到。

sort会按字典序排列列表并自动去重，语法$(sort list)。说实话，构建系统里很少真的需要排序，但sort的作用更多是“规范化”。我遇到过重复把同一个源文件追加进变量然后导致链接符号重复定义的情况，用$(sort $(SRCS))能直接消除重复项。当然，如果你真心想保留顺序，就别用sort。

word、words、wordlist这三个是“按位置取词”的家族：

• $(words text)返回单词个数；
• $(word n,text)返回第 n 个单词，n 从 1 开始；
• $(wordlist start,end,text)返回第 start 到第 end 个单词。

这些函数用的频率不算高，但在写通用脚本时很实用。比如脚本里需要一个“取最后一项”的操作，就可以组合：

LAST_WORD := $(word $(words $(LIST)),$(LIST))

3. 实战案例：从源码收集到目标文件生成的完整字符串流水线

3.1 先定场景：用函数把分散源码自动整理成构建产物

字符串函数单独讲每一个都懂，但真正考验能力的是组合使用。下面我用一个模拟的跨平台数据采集项目来演示完整流程。假设目录结构是这样的：

project/ ├── Makefile ├── src/ │ ├── device/ │ │ ├── sensor.c │ │ ├── sensor.h │ │ └── camera.c │ ├── protocol/ │ │ ├── tcp_link.c │ │ └── modbus.c │ └── main.c └── build/

构建要求有两点：第一，自动收集src树下所有.c文件，并编译到build/obj/对应子目录下，保持目录结构；第二，链接成一个可执行文件bin/app。这种需求如果不用函数，要么你把每个源文件路径写死，要么用递归wildcard配合patsubst，后者明显才是正道。

这里我说明一下，完整的多目录构建还有生成目录、依赖生成等技术，本篇专注字符串处理，所以目录生成等动作我会用最简单的方式处理。

3.2 源码收集与模式替换：wildcard + patsubst 组合

第一步是收集源文件，这里必须用wildcard函数。wildcard本身不是字符串处理函数，但它经常和patsubst搭配，所以放在一起讲：

SRC_DIR := src BUILD_DIR := build/obj SRCS := $(wildcard $(SRC_DIR)/*.c) \ $(wildcard $(SRC_DIR)/device/*.c) \ $(wildcard $(SRC_DIR)/protocol/*.c)

展开后SRCS大概长这样：

src/main.c src/device/sensor.c src/device/camera.c src/protocol/tcp_link.c src/protocol/modbus.c

接下来把src/前缀替换成build/obj/，把.c后缀替换成.o。这一步正是patsubst的主场。你可能会想直接写两个替换嵌套，但实际上patsubst的%可以捕获整个路径中间部分，一步到位：

OBJS := $(patsubst $(SRC_DIR)/%.c,$(BUILD_DIR)/%.o,$(SRCS))

展开后的OBJS：

build/obj/main.o build/obj/device/sensor.o build/obj/device/camera.o build/obj/protocol/tcp_link.o build/obj/protocol/modbus.o

这个替换的巧妙之处在于：%捕获的是src/和.c之间的完整中间内容，包括device/、protocol/这些子目录路径，然后原样替换到build/obj/和.o之间。这样目标文件就自动保持了源码目录结构。

为了验证结果，强烈建议在写 Makefile 时先用调试手段打印变量再继续：

$(info SRCS := $(SRCS)) $(info OBJS := $(OBJS))

运行make就能看到输出。我每次写复杂函数链都会先打一遍，确认参数和模式没错再往下走。

3.3 二次筛选与清理：filter + strip 在编译选项中的应用

源文件和目标文件列表已经自动生成，但实际工程还有个常见需求：区分“设备层源码”和“协议层源码”，比如设备层源码要额外加一个编译宏，协议层不加。这时候filter就该上场了：

DEVICE_SRCS := $(filter $(SRC_DIR)/device/%.c,$(SRCS)) PROTOCOL_SRCS := $(filter $(SRC_DIR)/protocol/%.c,$(SRCS)) DEVICE_OBJS := $(patsubst $(SRC_DIR)/%.c,$(BUILD_DIR)/%.o,$(DEVICE_SRCS))

等等，这里有个细节要注意。filter的 pattern 里写了$(SRC_DIR)/device/%.c，意思是只保留路径前缀为src/device/且后缀为.c的单词。如果SRCS里混进了src/device_old/x.c，它不会被匹配到，因为filter是整体单词匹配，单词src/device_old/x.c不满足src/device/%.c这个模式。这种“严格前缀+通配后缀”的用法，适合目录结构清晰的工程。

接下来再看strip的组合价值。假设用户通过环境变量传入了一个EXTRA_CFLAGS，内容很可能是这样乱七八糟的：

EXTRA_CFLAGS := " -DUSE_SENSOR -DENABLE_LOG "

直接拼进CFLAGS再传给编译命令，虽然多数编译器能容忍多余空格，但如果你在 Makefile 里要对它做精确判断，比如“是否包含-DENABLE_LOG”，结果会因为首尾空格导致不确定行为。先处理：

EXTRA_CFLAGS := $(strip $(EXTRA_CFLAGS))

这样变量就变成了-DUSE_SENSOR -DENABLE_LOG，再做findstring或filter判断都稳定得多。这个“先清理，再使用”的习惯，能帮你省掉大量“为什么这台机器上编译参数不对”的问题。

3.4 完整可运行的 Makefile 示例

把前面所有步骤拼起来，完整示例是这样：

CC := gcc CFLAGS := -Wall -O2 EXTRA_CFLAGS := -DUSE_SENSOR -DENABLE_LOG SRC_DIR := src BUILD_DIR := build/obj BIN_DIR := bin TARGET := $(BIN_DIR)/app SRCS := $(wildcard $(SRC_DIR)/*.c) \ $(wildcard $(SRC_DIR)/device/*.c) \ $(wildcard $(SRC_DIR)/protocol/*.c) OBJS := $(patsubst $(SRC_DIR)/%.c,$(BUILD_DIR)/%.o,$(SRCS)) DEVICE_SRCS := $(filter $(SRC_DIR)/device/%.c,$(SRCS)) PROTOCOL_SRCS := $(filter $(SRC_DIR)/protocol/%.c,$(SRCS)) # 清理外部传入的编译选项 EXTRA_CFLAGS := $(strip $(EXTRA_CFLAGS)) ALL_CFLAGS := $(strip $(CFLAGS) $(EXTRA_CFLAGS)) # 调试输出（确认无误后删除） $(info SRCS: $(SRCS)) $(info OBJS: $(OBJS)) $(info DEVICE_SRCS: $(DEVICE_SRCS)) $(info PROTOCOL_SRCS: $(PROTOCOL_SRCS)) .PHONY: all clean all: $(TARGET) $(TARGET): $(OBJS) @mkdir -p $(BIN_DIR) $(CC) $(OBJS) -o $@ $(BUILD_DIR)/%.o: $(SRC_DIR)/%.c @mkdir -p $(dir $@) $(CC) $(ALL_CFLAGS) -c $< -o $@ clean: rm -rf $(BUILD_DIR) $(BIN_DIR)

初次运行会先看到打印的变量信息，然后创建目录、编译、链接。这个例子把patsubst、filter、strip全部串进了一条真实的构建流水线。你在自己的工程里完全可以照着这个骨架改路径和文件名，几分钟就能跑起来。

提示：$(dir $@)是另一个内置函数，用来取目标文件所在目录，配合@mkdir -p可以自动创建每一层目录。虽然本篇重点是字符串函数，但这个组合很实用，顺手推荐。

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

4.1 patsubst 不生效？先查这5个地方

patsubst表面很简单，实际执行却总有“为什么没变”的困惑。根据我的经验，九成问题出在下面几个地方：

我遇到过最隐蔽的一次，是源文件列表里混进了一个以空格结尾的单词，patsubst把空单词也保留下来，导致后面的编译规则里出现了一个不存在的目标文件。排查了很久才想到是“空单词”问题。从此我养成习惯：凡是外部传入的列表变量，一律先strip再使用。

4.2 filter 结果不符合预期：空格与空值才是真凶

filter不像findstring那样做子串匹配，它严格按单词匹配。最常见的失败场景：

FILES := main.c utils.h protocol.c HDR := $(filter %.h,$(FILES)) # 结果是 utils.h DBG := $(filter debug,$(FILES)) # 结果是空

这里的空结果不是 bug，是filter的语义决定的。如果你真的想在一个可执行文件列表里找某个文件名，应该先确认这个文件名是不是一个完整的单词。比如：

TARGET_LIST := app demo test HAS_DEMO := $(filter demo,$(TARGET_LIST)) # 结果是 demo

只要demo作为独立单词出现，就能匹配成功。如果是demo-v2，那就匹配不到。

还有一个常见问题：filter-out配多模式时，空格分隔多个模式，但模式之间如果有空行或缩进，缩进部分会被当成模式的一部分，导致匹配失效。这点在写长行时尤其容易中招。我一般会坚持一行只写一个模式，宁可分行也不在模式列表里换行缩进。

4.3 调试字符串函数的几种有效打法

Make 没有内置的 REPL，但调试函数并不难。最常用的方法有三个。

第一，$(info ...)或者$(warning ...)打印中间变量。info只是在标准输出打印一行，warning则会额外显示 Makefile 文件名和行号，适合定位“这个打印来自哪一行”。我用得最多的是：

$(info DEBUG -> patsubst result: $(patsubst %.c,%.o,main.c))

第二，用命令行传入一个“空目标”来查看变量，而不影响正常构建。比如：

.PHONY: debug-vars debug-vars: @echo "SRCS = $(SRCS)" @echo "OBJS = $(OBJS)"

运行make debug-vars就能输出当前项目的变量快照。这比反复插入$(info)再删除要干净得多。

第三，用make -n做“演习”。它会打印将要执行的命令，不真正执行。字符串函数的结果会体现在展开后的命令文本里，你可以从中判断替换是否生效。不过要注意，如果目标里用到了@开头的静默命令，-n仍会输出命令，说明函数已经展开成功了。

如果函数极其复杂、一次展开看不明白，我还有一个土办法：单独建一个test.mk，只放变量定义和打印逻辑，然后用make -f test.mk运行。这样不会污染主 Makefile，修改起来也快。

5. 进阶玩法与我的实操心得

5.1 用 filter + findstring 做条件判断的巧用

字符串函数不只是用来生成列表，还能直接参与条件逻辑。我之前做过一个模拟的跨平台系统，需要在存在某类文件时自动切换编译宏，靠的就是ifneq+filter：

ifneq ($(filter $(SRC_DIR)/device/%.c,$(SRCS)),) DEVICE_MODE := -DDEVICE_ENABLE else DEVICE_MODE := endif

这个写法的意思是：如果在源文件列表里能筛出src/device/%.c类型文件，说明工程里有设备层代码，那么定义宏；否则不定义。相比人工维护一个“是否包含设备层”的开关变量，这种自动判断更可靠，因为它直接基于真实的文件情况。

另一个场景是检查当前工具链版本。比如：

GCC_VERSION := $(shell gcc -dumpversion)

但是shell返回的字符串可能带换行，这时findstring可以配合strip做稳定判断：

GCC_VERSION := $(strip $(shell gcc -dumpversion)) ifneq ($(findstring 13,$(GCC_VERSION)),) $(info using gcc 13 or newer) endif

注意findstring 13会匹配到13、13.2等任意包含 13 的字符串，如果你要精确匹配“主版本等于 13”，还得结合word取第一个以.分隔的段。从这里就能看出，字符串函数单看都简单，组合起来才是真正的威力所在。

5.2 字符串函数组合的几种经典模式

我把自己经常用的组合整理成了几个“套路”，分享出来。第一个套路是“收集-清洗-替换三连”：

RAW_SRCS := $(wildcard src/**/*.c) # 假设你配置了通配符特性 SRCS := $(sort $(strip $(RAW_SRCS))) # 去重、清理、排序 OBJS := $(patsubst %.c,%.o,$(SRCS)) # 替换后缀

先用wildcard收集，再用sort去重排序，再用strip清理空格，最后用patsubst生成目标。这套流程能覆盖大多数源文件收集需求，我几乎每个项目都这么写。

第二个套路是“筛选-分组”：

ALL_FILES := $(wildcard src/*) C_FILES := $(filter %.c,$(ALL_FILES)) H_FILES := $(filter %.h,$(ALL_FILES)) OTHER_FILES := $(filter-out %.c %.h,$(ALL_FILES))

一个filter加一个filter-out，就能把混在一起的资源文件按类型分组，后续分别处理头文件依赖、编译源文件、拷贝资源文件。

第三个套路是“判定-默认值”：

DEBUG_OPTION := $(if $(findstring DEBUG,$(strip $(CFLAGS))),-g3,-g0)

如果CFLAGS里已经包含了DEBUG字样，就使用-g3，否则-g0。这个写法非常紧凑，适合在变量定义阶段根据其他变量动态决定当前变量。

组合使用的时候，有个经验性的建议：顺着数据流从左到右写，每一步只做一件事，用注释标注每一步的结果。Makefile 的变量展开是即时文本替换，读起来比较绕，注释写得稍微多一点，三个月后回来维护才不会“这是什么鬼”。

5.3 写给初学者的最后提醒

整个字符串函数体系学下来，我的感受是：函数本身不复杂，复杂的是怎么根据场景选择合适的函数、怎么避免空格和空值带来的隐性问题。刚开始练习时，不要试图一次写出完整的函数链，而是先拆开写，每一个中间结果都用$(info)打出来确认。等你对patsubst、filter、strip的行为有了肌肉记忆，再考虑合并成一行。

我也见过一些追求“一行流”的写法，把所有函数嵌套在一行里，输出结果确实很酷，但可读性太差。Makefile 的第一目标是“可靠地描述构建过程”，第二目标才是“简洁”。如果一行函数复杂到你需要写注释解释，那不如拆成几行容易阅读的中间变量。

说一个我自己的习惯：在写完一个关键函数后，我会刻意保留一行调试输出作为“临时日志”，等项目彻底稳定后再删掉。这不是洁癖，而是为了让下一个接手代码的人（包括三个月后的自己）能快速看到变量展开的真实形态，减少猜谜时间。字符串处理这种纯文本操作，肉眼看到结果比读十遍代码都管用。

最后再分享一个小技巧：如果某个字符串函数的结果和你预期不一致，不要马上怀疑函数 bug，先打印原始变量，再看模式里的空格和缩进。Makefile 里 90% 的“函数不生效”都是数据问题，不是函数问题。文本进、文本出，只要进的数据干净，出的结果自然可控。