2. 构建工具选型：Makefile vs CMake vs Bazel vs Gradle
说到多目录构建，选哪个工具往往是第一个让人头疼的问题。我见过不少团队，一开始随便选了个工具，结果项目大了以后改起来痛不欲生。今天我就把这四个主流工具掰开揉碎讲清楚，帮你少走弯路。
2.1 Makefile：老牌工具，简单粗暴
Makefile 是 Unix 世界的元老。说白了，它就是一套基于「目标-依赖-命令」的规则引擎。你告诉它要生成什么，依赖哪些文件，它就去执行对应的 shell 命令。
我个人的习惯是，如果项目就两三个目录，文件不超过 50 个，Makefile 完全够用。举个例子：
# 一个简单的多目录 Makefile
CC = gcc
CFLAGS = -Wall -Iinclude
# 递归查找所有 .c 文件
SRCS = $(wildcard src/*.c)
OBJS = $(SRCS:.c=.o)
app: $(OBJS)
$(CC) -o $@ $^
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
clean:
rm -f app $(OBJS)
嗯，这里要注意，Makefile 的递归构建是个坑。我在项目中遇到过，当目录层级超过 3 层时，Makefile 的依赖追踪就开始变得混乱。你想想看，每个子目录都要写一个 Makefile，然后主 Makefile 用 make -C 去调用，维护起来简直像在玩俄罗斯套娃。
make clean，否则增量编译会漏掉依赖。后来我花了整整两天才把自动依赖生成搞定。如果你项目超过 100 个文件，建议直接看下一个工具。
2.2 CMake：跨平台的事实标准
CMake 解决了 Makefile 最大的痛点——跨平台。它不直接构建，而是生成对应平台的构建文件（Makefile、Ninja、Visual Studio 工程等）。说白了，CMake 是「构建系统的构建系统」。
| 特性 | CMake | Makefile |
|---|---|---|
| 跨平台 | ✅ 原生支持 | ❌ 需手动适配 |
| 多目录支持 | ✅ add_subdirectory | ⚠️ 递归调用 |
| 第三方库管理 | ✅ find_package | ❌ 手动指定路径 |
| 学习曲线 | 中等 | 低 |
我个人建议，只要是 C/C++ 项目，并且需要跨平台，直接上 CMake。它的 add_subdirectory 机制让多目录管理变得非常优雅：
# 顶层 CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(MyProject)
add_subdirectory(lib/core)
add_subdirectory(lib/network)
add_subdirectory(app)
# lib/core/CMakeLists.txt
add_library(core core.cpp core.h)
target_include_directories(core PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
# app/CMakeLists.txt
add_executable(app main.cpp)
target_link_libraries(app core network)
你看，每个目录只管自己的事，顶层只负责组合。我在项目中遇到过最爽的一次，是把一个 30 个目录的遗留项目从 Makefile 迁移到 CMake，只花了一天时间，而且后续再也没出现过「编译找不到头文件」这种低级错误。
target_include_directories 用 PUBLIC 还是 PRIVATE？我的经验是：如果这个头文件被其他模块引用，就用 PUBLIC；如果只是内部实现细节，用 PRIVATE。这样能有效控制头文件泄漏。
2.3 Bazel：Google 出品，大型项目利器
Bazel 是 Google 内部构建工具 Blaze 的开源版本。它最大的特点是「增量构建」和「沙盒执行」。说白了，每次构建都是从头开始，但因为有缓存，实际上只编译改动过的文件。
为什么会这样？因为 Bazel 把每个构建目标都看作一个独立的「沙盒」，输入和输出都是确定的。这听起来很重，但对于超大型项目来说，这恰恰是优势。
# BUILD 文件示例
cc_library(
name = "core",
srcs = ["core.cpp"],
hdrs = ["core.h"],
visibility = ["//app:__pkg__"],
)
cc_binary(
name = "app",
srcs = ["main.cpp"],
deps = [
"//lib/core",
"//lib/network",
],
)
嗯，这里要注意，Bazel 的学习曲线确实陡。我记得第一次用的时候，光是理解 WORKSPACE 文件和 BUILD 文件的区别就花了两天。但一旦上手，你会发现它的依赖管理简直像艺术品——每个目标都清清楚楚，不会出现「这个库到底被谁引用了」的困惑。
2.4 Gradle：Java 生态的王者
Gradle 是 Android 和 Java 项目的标配。它基于 Groovy/Kotlin DSL，比 Maven 的 XML 配置灵活得多。说白了，Gradle 就是一个「可编程的构建系统」——你可以在构建脚本里写逻辑、写循环、写条件判断。
| 特性 | Gradle | Maven | Bazel |
|---|---|---|---|
| 配置方式 | DSL（Groovy/Kotlin） | XML | Starlark |
| 增量构建 | ✅ 支持 | ⚠️ 有限 | ✅ 原生 |
| 多项目支持 | ✅ settings.gradle | ✅ 父 POM | ✅ WORKSPACE |
| Java 生态 | ✅ 最佳 | ✅ 成熟 | ⚠️ 一般 |
我个人习惯，只要是 Java/Kotlin 项目，无脑选 Gradle。它的多项目配置非常直观：
// settings.gradle
rootProject.name = 'my-project'
include 'lib:core'
include 'lib:network'
include 'app'
// app/build.gradle
dependencies {
implementation project(':lib:core')
implementation project(':lib:network')
}
你想想看，Gradle 的 implementation 和 api 依赖配置，比 Maven 的 compile 和 provided 清晰多了。我在项目中遇到过最头疼的事，就是 Maven 的依赖冲突——两个 jar 包引了同一个库的不同版本，Maven 只会默默选一个，而 Gradle 会明确告诉你冲突在哪里。
--build-cache 选项一定要开。我见过很多团队没用这个，每次构建都重新编译所有代码。开了之后，增量构建速度能提升 5-10 倍，尤其是 CI 环境里效果更明显。
2.5 选型决策树
说了这么多，到底怎么选？我总结了一个简单的决策逻辑：
- 项目小于 50 个文件，纯 C/C++，不跨平台 → Makefile，简单直接
- C/C++ 项目，需要跨平台，文件 50-500 → CMake，业界标准
- 超大型项目（500+ 文件），多语言混编，需要严格可复现 → Bazel，值得投入
- Java/Kotlin 项目，Android 或后端 → Gradle，没有之一
嗯，最后说一句，没有完美的工具。我见过用 Makefile 管理 500 个文件的狠人，也见过用 Bazel 管理 10 个文件的「杀鸡用牛刀」。关键是你团队的习惯和项目的实际需求。选一个大家都能接受的，比选一个「理论上最好」的更重要。