1.1 make 是怎样解决项目的构建问题的？#

程序员们往往会靠抽象和封装解决复杂的逻辑问题，靠建立标准或协议解决有争议的问题。

make 也不例外。为了让项目的构建更简单，Makefile 中隐藏了大量规则使得它的编写变得更为简单（后面详细介绍）。并且它将通用的构建逻辑封装成了 Makefile 世界中的底层逻辑，比如：

• 构建规则的抽象，只有先决条件发生变化或发生修改才会去真正执行构建动作；
• make 中的变量规则，使得你能通过环境变量、命令行变量、文件内声明的变量去设定构建需要的变量；
• 根据目标进行先决条件和构建命令的自动推导，进一步简化常见语言 Makefile 的编写；

从这里可以看到，初代编译系统的特性点为：

• 比对目标和先决条件的更新时间，仅编译必要的部分；
• 用隐藏规则、自动推导等手段简化构建文件的编写，让开发者专注于功能开发而不是项目构建；
• 利用变量加载规则实现多模式/跨环境的项目构建；

1.2 make 的后继者们#

make 成为项目构建界的第一块基石之后，起到了抛砖引玉的作用。很多人基于 make 工具或思想对其进行封装、扩展或重构。下面介绍几个比较常见的工具。

2.1 meson#

Meson 是一个现代化的构建系统，设计目标是提供极致的构建速度和出色的用户体验。它于 2013 年由 Jussi Pakkanen 发起，其核心理念是「快」——不仅构建速度快，配置文件的编写和维护也应该快速便捷。

与 CMake 类似，Meson 也采用声明式语法描述项目结构，但它的语法更加简洁直观。Meson 的配置文件称为 meson.build，使用一种类似 Python 的领域特定语言（DSL），而非 CMake 那样繁琐的命令式语法。这种设计使得 Meson 配置文件更易读、更易维护。

1
# meson.build 示例
2
project('myapp', 'c', version: '1.0.0')
3

4
# 查找依赖
5
dependency('glib-2.0')
6
dependency('gtk+-3.0')
7

8
# 定义构建目标
9
executable('myapp',
10
  'src/main.c',
11
  'src/utils.c',
12
  dependencies: [glib_dep, gtk_dep],
13
  install: true
14
)
15

16
# 添加测试
17
test('basic', executable('test_basic', 'tests/basic.c'))

Meson 的一个显著特点是它原生支持多种现代开发工作流：

• 跨平台支持：原生支持 Linux、Windows、macOS，无需额外的配置文件
• 依赖管理：内置 Wrap 依赖系统，可直接从 Git 仓库或 tarball 获取依赖
• 多语言支持：支持 C、C++、D、Fortran、Java、Rust、C# 等多种语言
• 内置功能：原生支持单元测试、代码覆盖率、静态分析、文档生成等

Meson 的另一个重要特性是其可扩展的模块系统。通过内置模块，Meson 可以处理国际化和本地化（i18n）、RPM 包生成、Qt 资源编译等常见任务，无需额外编写脚本。

在性能方面，Meson 对增量构建进行了深度优化。它会精确追踪文件变化，仅重新编译受影响的目标。同时，Meson 与 Ninja 构建系统紧密集成，后者专为高速构建而设计，两者配合能够实现极快的构建速度。

2.2 ninja#

Ninja 是一个专注于速度的小型构建系统。它由 Evan Martin 于 2010 年在 Google 开发，最初是为了解决 Chromium 项目的编译速度问题。Ninja 的设计哲学非常明确：不做任何决策，只负责快速执行。

与 make 不同，Ninja 没有「隐式规则」或「自动推导」。它要求构建文件显式列出每一个构建规则和依赖关系。这意味着 Ninja 本身不负责「如何」构建项目，而只负责「尽可能快地」执行构建命令。

1
# build.ninja 示例
2
rule cc
3
  command = gcc -c $in -o $out
4

5
rule link
6
  command = gcc $in -o $out
7

8
build main.o: cc main.c
9
build utils.o: cc utils.c
10
build myapp: link main.o utils.o

Ninja 的核心优势在于其构建图的优化能力。它会分析整个构建依赖图，识别并行构建机会，并尽可能多地并行执行不相关的构建任务。这使得 Ninja 在多核 CPU 上能够充分利用硬件性能。

Ninja 的另一个关键设计是「最小重构建」。它通过精确的时间戳比对和依赖追踪，确保只重新编译真正需要更新的文件。这种精确性使得增量构建非常高效——即使项目有数万个文件，修改一个小文件后的重编译通常只需几秒钟。

正是因为 Ninja 的高效，它成为了许多现代构建系统的后端选择。CMake、Meson 等都可以生成 Ninja 构建文件，然后由 Ninja 执行实际的编译工作。这种「前端生成器 + 后端执行器」的架构，结合了声明式配置的易用性和命令式执行的高效性。

Ninja 几乎从不被直接编写。开发者通常使用 CMake、Meson 等高级工具生成 build.ninja 文件，然后让 Ninja 执行构建。这种分工让各工具专注于自己擅长的领域：

• 高层构建系统（CMake、Meson）：负责解析项目结构、管理依赖、生成构建规则
• 低层构建系统（Ninja）：负责高效调度和执行编译任务

2.3 monorepo、bazel 与分布式构建#

随着软件项目规模的增长，传统的单仓库构建方式逐渐暴露出局限性。现代大型项目往往需要管理数十甚至上百个相互依赖的组件，这就催生了 monorepo（单一仓库）管理方式和配套的构建工具。

Monorepo 是一种将多个项目或组件放在同一个代码仓库中进行管理的策略。与多仓库（multirepo）方式相比，monorepo 的优势在于：

• 原子性提交：跨多个组件的修改可以在一次提交中完成
• 代码共享：不同项目可以直接引用共享代码，无需发布和版本管理
• 统一工具链：所有项目使用相同的构建工具和配置
• 简化依赖管理：不需要维护多个仓库之间的依赖关系

然而，monorepo 也带来了构建挑战。当仓库中包含数千个目标时，传统构建工具的增量构建能力往往不够精确，可能导致不必要的重新构建。这正是 Bazel 等 monorepo 专用构建工具大显身手的领域。

Bazel 是 Google 开源的构建和测试工具，它继承了 Google 内部 Blaze 构建系统的设计理念。Bazel 的核心特性包括：

1
# BUILD 文件示例
2
cc_binary(
3
    name = "myapp",
4
    srcs = ["main.cc", "util.cc"],
5
    deps = [
6
        "//lib:common",
7
        "//lib:network",
8
    ],
9
)
10

11
cc_library(
12
    name = "common",
13
    srcs = ["common.cc"],
14
    hdrs = ["common.h"],
15
    visibility = ["//visibility:public"],
16
)

Bazel 的设计有几个关键特点：

Hermetic Build（封闭构建）：Bazel 构建过程是完全确定的。它使用沙箱机制隔离每次构建，确保构建结果只受输入文件和构建规则的影响，而不受系统环境的影响。这意味着在不同机器上执行相同的构建会得到完全相同的结果。

精确的依赖分析：Bazel 要求显式声明所有依赖关系。这种显式声明使得 Bazel 能够精确判断哪些目标需要重新构建，从而实现真正高效的增量构建。即使项目有数万个目标，修改一个文件后 Bazel 也能快速确定受影响的目标。

分布式构建：Bazel 支持分布式构建执行，可以将编译任务分发到多台机器上并行执行。这对于大型项目尤为重要——Google 内部的构建集群可以在几分钟内完成数百万行代码的重新编译。

远程缓存：Bazel 可以使用远程缓存存储构建产物。如果其他开发者已经构建过相同的目标，你可以直接从缓存获取构建结果，无需本地重新编译。这大大加速了 CI/CD 流水线和团队协作效率。

除了 Bazel，monorepo 生态中还有其他重要的构建工具：

• Pants：由 Twitter 开发，支持 Python、Java、Scala 等语言，专注于细粒度的依赖管理
• Buck：Facebook 开发的构建系统，主要服务于 Java 和 Android 项目
• Nx：面向 JavaScript/TypeScript monorepo 的构建系统，提供智能的增量构建和缓存机制
• Turborepo：专为 JavaScript/TypeScript 设计的高性能构建系统，强调远程缓存和分布式任务执行

这些工具虽然各有侧重，但都遵循相似的设计原则：显式依赖声明、精确的增量构建、支持分布式执行。它们共同代表了构建系统在规模化场景下的演进方向。

在选择构建工具时，需要根据项目规模和团队情况做出权衡：

4.1 Makefile 简要笔记#

已知，对于解决一个问题，确定执行方案后，无论你切换何类工具都不能降低方案的复杂度，你最多只能将某些复杂度隐藏到某个工具下面。make 也是如此，它将项目构建时的常见规则隐藏了起来，使得 Makefile 的编写更加容易与简洁。为了更清晰地理解 make 到底做了什么，为了能编写更加正确的 Makefile，需要了解 make 的内部世界。

1
# 默认的命令变量
2
AR = ar
3
AS = as
4
CC = cc
5
CXX = g++
6
CO = co
7
CPP = $(CC) –E
8
FC = f77
9
GET = get
10
LEX = lex
11
PC = pc
12
YACC = yacc
13
YACCR = –r
14
MAKEINFO = makeinfo
15
TEX = tex
16
TEXI2DVI = texi2dvi
17
WEAVE = weave
18
CWEAVE = cweave
19
TANGLE = tangle
20
CTANGLE = ctangle
21
RM = rm –f
22

23
# 默认的命令行参数变量
24
ARFLAGS : 函数库打包程序AR命令的参数。默认值是 rv
25
ASFLAGS : 汇编语言编译器参数。（当明显地调用 .s 或 .S 文件时）
26
CFLAGS : C语言编译器参数。
27
CXXFLAGS : C++语言编译器参数。
28
COFLAGS : RCS命令参数。
29
CPPFLAGS : C预处理器参数。（ C 和 Fortran 编译器也会用到）。
30
FFLAGS : Fortran语言编译器参数。
31
GFLAGS : SCCS "get"程序参数。
32
LDFLAGS : 链接器参数。（如： ld ）
33
LFLAGS : Lex文法分析器参数。
34
PFLAGS : Pascal语言编译器参数。
35
RFLAGS : Ratfor 程序的Fortran 编译器参数。
36
YFLAGS : Yacc文法分析器参数。
37

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

4.2 有用的 Makefile 片段#

构建项目时，可能需要提前安装一些工具或者库。这个过程可以提前执行写好的脚本实现，也可以写在 makefile 中每次都重新安装一遍。但更优雅的还是先对其进行检查，若不存在再进行安装。详见如下代码片段：

1
## 通过定义形如 tools.verify.<toolName> 依赖来达到检查 <toolName> 是否存在，若不存在则调用 tools.install.<toolName> 的结果
2
.PHONY: tools.verify.%
3
tools.verify.%:
4
  @if ! which $* &>/dev/null; then $(MAKE) tools.install.$*; fi
5

6
# 工具安装的包装
7
.PHONY: tools.install.%
8
tools.install.%:
9
  @echo "===========> Installing $*"
10
  @$(MAKE) install.$*
11

12
# 示例 go tools
13
install.git-chglog:
14
  @$(GO) install github.com/git-chglog/git-chglog/cmd/git-chglog@latest
15

16
# 示例 golang
17
install.golang:
18
  # 若觉得 yum 源不稳定，则可以写一个复杂但更可靠的脚本来实现工具的安装
19
  yum install go -y
20

21
# 示例，先进行代码生成，再构建 go 项目
22
build: tools.verify.golang tools.verify.git-chglog
23
  @codegen -type=int ${ROOT_DIR}/internal/pkg/code
24
  @$(GO) build ${ROOT_DIR}/cmd/demo.go

Golang 程序能轻松支持交叉编译，并且大多数 gopher 都约定将可执行文件入口定义到 cmd 目录中，所以参考下面的 makefile 片段能轻松实现 golang 的多平台编译：

1
# golang 专用，获取 cmd 目录下的所有编译目标，进行多平台构建
2
# 定义变量
3
GO_SUPPORTED_VERSIONS ?= 1.13|1.14|1.15|1.16|1.17|1.18|1.19|1.20
4
# 定义路径变量
5
ROOT_PACKAGE=/root/
6
OUTPUT_DIR=/root/
7
# 定义构建目标
8
COMMANDS ?= $(filter-out %.md, $(wildcard ${ROOT_DIR}/cmd/*))
9
BINS ?= $(foreach cmd,${COMMANDS},$(notdir ${cmd}))
10

11
.PHONY: go.build.verify
12
go.build.verify:
13
ifneq ($(shell $(GO) version | grep -q -E '\bgo($(GO_SUPPORTED_VERSIONS))\b' && echo 0 || echo 1), 0)
14
  $(error unsupported go version. Please make install one of the following supported version: '$(GO_SUPPORTED_VERSIONS)')
15
endif
16

17
.PHONY: go.build
18
go.build: go.build.verify $(addprefix go.build., $(addprefix $(PLATFORM)., $(BINS)))
19

20
.PHONY: go.build.multiarch
21
go.build.multiarch: go.build.verify $(foreach p,$(PLATFORMS),$(addprefix go.build., $(addprefix $(p)., $(BINS))))
22

23
.PHONY: go.build.%
24
go.build.%:
25
  $(eval COMMAND := $(word 2,$(subst ., ,$*)))
26
  $(eval PLATFORM := $(word 1,$(subst ., ,$*)))
27
  $(eval OS := $(word 1,$(subst _, ,$(PLATFORM))))
28
  $(eval ARCH := $(word 2,$(subst _, ,$(PLATFORM))))
29
  @echo "===========> Building binary $(COMMAND) $(VERSION) for $(OS) $(ARCH)"
30
  @mkdir -p $(OUTPUT_DIR)/platforms/$(OS)/$(ARCH)
31
  @CGO_ENABLED=0 GOOS=$(OS) GOARCH=$(ARCH) $(GO) build $(GO_BUILD_FLAGS) -o $(OUTPUT_DIR)/platforms/$(OS)/$(ARCH)/$(COMMAND)$(GO_OUT_EXT) $(ROOT_PACKAGE)/cmd/$(COMMAND)

参考现代 IDE 对项目的生命周期管理功能的支持，也可以使用 Makefile 实现如下目标的管理：

• 静态代码检查（lint）
• 单元测试（test）
• 编译（build）
• 镜像打包和发布（image/image.push）
• 清理（clean）
• 代码生成（gen）
• 部署（deploy）
• 发布（release）
• 帮助（help）
• 为文件头追加版权声明（add-copyright）
• 生成 API 文档（swagger）
• 生成项目静态站点（site）

Make 的学习资料非常丰富，所以这里就不对 make 的基础知识做过多介绍了，想系统学习一遍的读者可以参考下面的网站：

• GNU make - 官方文档
• 跟我一起写Makefile
• 《Go 语言项目开发实战》- 项目管理：如何编写高质量的Makefile？
• Practical Makefiles, by example