C++项目一旦上了规模，逐个文件敲编译命令的做法很快就会失灵。批量编译脚本把重复劳动交给机器，也让构建过程可复现、可审计。本文从最朴素的手写脚本讲起，逐步过渡到 Makefile、CMake 等自动化构建工具，帮助开发者根据项目规模选对方案。
一、逐文件编译为什么撑不住
一个几十个源文件的工程，靠手动执行命令会遇到三类问题：
- 效率低：每次改动都要重新输入或翻历史命令，容易漏编、错编；
- 不可复现：编译参数散落在终端历史里，换台机器或换个人就复现不出来；
- 无法增量：改动一个头文件却要全量重编，动辄等待数分钟。
批量编译脚本的本质，是把“编译哪些文件、用什么参数、输出到哪里”固化下来，让构建变成一条命令就能完成的事。
二、手写脚本的快速实现
小项目用一段 Shell 或批处理就够了。Linux 下的示例：
#!/bin/bash
mkdir -p build
SRC=$(find src -name '*.cpp')
g++ -std=c++17 -O2 -Iinclude $SRC -o build/app
Windows 下可以写一个 build.bat，用 for 循环遍历 .cpp 文件后统一调用 cl 或 g++。这个阶段的关键动作，是把头文件路径、宏定义、优化等级集中写进脚本，而不是散落在命令行历史里。
脚本跑通后建议立刻补两件事：一是在脚本里加入依赖库检查，缺库时直接报错退出；二是把脚本纳入版本控制，与代码同步演进。
三、从 Makefile 到 CMake：增量与跨平台
文件数过百后，全量重编的时间成本开始显现。Makefile 的价值在于依赖分析和增量构建，只重编真正被改动的文件：
CXX = g++
CXXFLAGS = -std=c++17 -O2 -Iinclude
SRCS = $(wildcard src/*.cpp)
OBJS = $(SRCS:.cpp=.o)
app: $(OBJS)
$(CXX) $^ -o $@
%.o: %.cpp
$(CXX) $(CXXFLAGS) -c $< -o $@
执行 make 时，工具自动比对时间戳，跳过无需重编的目标，中型项目的构建时间往往能压缩一个数量级。
一旦项目要在 Windows、Linux、macOS 之间迁移，或需要管理第三方依赖，手写 Makefile 就力不从心了。CMake 用一份 CMakeLists.txt 描述构建逻辑，再按需生成各平台的原生工程：
cmake_minimum_required(VERSION 3.15)
project(app CXX)
file(GLOB SRCS src/*.cpp)
add_executable(app ${SRCS})
target_include_directories(app PRIVATE include)
CMake 还能与 vcpkg、Conan 等包管理器顺畅配合，可生成 compile_commands.json 供 clangd 做代码分析，主流 IDE 支持也很成熟。
四、落地建议与常见坑
- 选型按规模走：几个文件用脚本，几十个用 Make，跨平台或多人协作直接上 CMake；
- 构建脚本同样是代码，要写注释、做版本管理、跟随需求迭代；
- 在 CI 流水线中固定跑同一条构建命令，保证本地与服务器行为一致；
- 头文件依赖不完整会导致增量编译出错，可用 g++ 的 -MMD 选项自动生成依赖文件；
- 路径含空格常导致脚本解析失败，变量引用记得加引号。
从手写脚本到自动化构建工具，本质是让构建信息从“人的记忆”迁移到“机器可执行的描述”。越早完成这一步，团队在协作和持续集成上就越省力。
