甘剑平我在带新人的时候特别喜欢问一个问题：你写过Makefile吗？十个里面有七个会愣一下，然后说“我一般直接gcc……”。这个答案我太熟了，因为我自己也是从这个阶段过来的。一个main.c确实不需要Makefile，gcc一条命令就结束了。但当你面前是三十个源文件、五个头文件、还要区分Debug和Release的时候，再手敲gcc就是跟自己过不去。Makefile就是Linux下绕不开的“编译编排工具”，它解决的问题很朴素：哪些文件需要重新编译、用什么命令编译、怎么处理依赖关系。这篇文章我想用五次代码结构的迭代，把Makefile的原理和知识直白地拆给你看。
网上讲Makefile的文章不少，菜鸟教程里也有现成的语法表。但很多人看完还是不会写，原因很简单：语法是死的，代码结构是活的。今天我不打算按语法书的方式罗列规则，而是从一版很笨拙的Makefile开始，一步一步迭代到一个能搬进真实项目的工程化Makefile。每一步改什么、为什么改、改完解决什么，都会说清楚。整个过程只要你有一台Linux机器，或者哪怕装了WSL的Windows，都能跟着跑一遍。我要用的示例项目是一个叫logfilter的日志关键词过滤小工具，全程贯穿五次迭代，这样你就能清楚看到同一个项目在不同阶段的Makefile到底差在哪里。
1. 先搞清楚make在做什么：一篇最简单的菜谱
1.1 你是不是也这样编译过项目
很多人的Linux C开发日常是这样的：写一个main.c，一条gcc -o app main.c编译完事。源文件变成两个、三个，命令就变成gcc -o app main.c utils.c logger.c。变成三十个的时候就彻底崩了——命令行长到不想看，每次改一行代码都要把所有文件重新编译一遍，几十秒甚至几分钟就这么没了。
make解决的就是这个事。它维护了一张“构建关系图”，你只要告诉它最终目标是什么、每个目标依赖哪些文件、用什么命令生成，它就能自己判断哪些文件需要重新编译，哪些可以直接跳过。这就是Linux下几乎所有C/C++项目的构建基础。你能看到的大大小小开源项目，哪怕最终用的是CMake、Ninja，底层逻辑也都是这一套。
1.2 程序从源码到可执行文件要经历什么
要理解make为什么这么设计，得先回到编译本身。一个C程序变成可执行