AI 可能出错，请核对原文 在独立页面打开
问文档
目录

Make / CMake / Meson 构建系统

9 分钟
本页目录

构建系统解决的是“为了得到这个产物，哪些输入必须先准备好，什么变化要求重做哪些步骤”。写出一条能编译的命令只是起点；增量构建、并行和依赖传播是否正确，取决于图是否完整。

Make 根据规则与文件状态执行任务。CMake 和 Meson 通常先配置、生成后端构建描述，再交给 Ninja、Make 等执行器。不能把 CMake 的配置阶段时间直接与 Ninja 的编译时间比较，得出某种语言天生构建更慢。

同一个最小项目

以下三个方案分别构建同一组文件，源码位于项目根目录：

/* lib.h */
#ifndef DEMO_LIB_H
#define DEMO_LIB_H
int twice(int x);
#endif

/* lib.c */
#include "lib.h"
int twice(int x) { return x * 2; }

/* main.c */
#include "lib.h"
int main(void) { return twice(21) == 42 ? 0 : 1; }
增量构建依据依赖图：公共头文件变化影响两次编译 lib.h main.c lib.c main.o lib.o libdemo.a prog main.o 与 lib.o 可并行；链接需要 main.o 和更新后的静态库都已完成。

修改 lib.c 应重新构建库并链接；修改公共头文件 lib.h 应让两个使用者重新编译。无修改再构建，应该没有不必要的编译动作。遗漏这条头文件依赖可能造成旧声明与新库混用，仅“全量构建成功”发现不了这个问题。

GNU Make：规则、变量与自动依赖

保存为 Makefile。下面配方行的第一个字符是实际 Tab，不能换成普通空格：

.DEFAULT_GOAL := all
CC ?= cc
AR ?= ar
CFLAGS ?= -O2 -g -Wall -Wextra
CPPFLAGS ?=
LDFLAGS ?=
LDLIBS ?=
OBJS := main.o lib.o

.PHONY: all clean
all: prog

prog: main.o libdemo.a
	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)

libdemo.a: lib.o
	$(AR) rcs $@ $^

%.o: %.c Makefile
	$(CC) $(CPPFLAGS) $(CFLAGS) -MMD -MP -MF $(@:.o=.d) -MT $@ -c $< -o $@

-include $(OBJS:.o=.d)

clean:
	$(RM) $(OBJS) $(OBJS:.o=.d) libdemo.a prog

这里 $@ 是目标，$< 是第一个前置依赖，$^ 是去重后的前置依赖列表。库参数放在引用它的对象之后，是传统静态库提取规则下常见的正确顺序。

CPPFLAGS 放预处理参数，CFLAGS 放 C 编译参数，LDFLAGS 放链接选项，LDLIBS 放 -lm 等库依赖。分类使调用者能覆盖其中一类而不误伤另一阶段。

编译时顺带生成每个对象的 .d，-MMD 通常省略系统头依赖，-MP 为头文件生成辅助空规则，-include 允许第一次尚无 .d。Make 读取生成的文件后才能知道间接 include 关系。GNU Make 自动前置依赖

make -j4
./prog
make

Make 主要依据时间戳和依赖判断是否更新，默认不记录“命令行参数变了”。本例把 Makefile 本身作为对象依赖，编辑文件会重编译，但命令行改 CFLAGS 仍不会自动让旧对象失效；实际项目可用配置签名、分构建目录，或在切换配置时清理。

生成头文件还必须明确依赖生成动作；首次构建前没有 .d 时，仅靠自动扫描不能保证生成器先运行。输出目录一般适合作为 order-only 前置条件，避免目录时间戳变化触发不必要的重编译。

CMake：target 携带使用需求

保存为 CMakeLists.txt：

cmake_minimum_required(VERSION 3.16)
project(demo VERSION 1.0 LANGUAGES C)

add_library(demo STATIC lib.c)
target_include_directories(demo PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}")
target_compile_features(demo PUBLIC c_std_11)

add_executable(prog main.c)
target_link_libraries(prog PRIVATE demo)

cmake -S . -B build-cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
cmake --build build-cmake --parallel 4
./build-cmake/prog

PUBLIC 表示构建 demo 自己和使用 demo 的目标都需要该属性；PRIVATE 只服务于目标自身，INTERFACE 只传给使用者。头文件若公开依赖某个类型、编译定义或语言特性，就要考虑相应使用需求是否应传播。CMake 构建系统

静态库的“实现依赖不公开”不等于最终链接永远不需要它；构建系统会按目标种类处理链接依赖传播。应使用目标关系，不要把 include 路径、库名和全局 flags 到处复制。

CMAKE_BUILD_TYPE 适用于示例的单配置生成器。多配置生成器通常在构建时通过 --config Release 选择，不能把两种模型混用。编译数据库记录实际编译命令，适合 clangd 等工具，见 LSP 与语言服务器。

Meson：显式声明目标与依赖对象

保存为 meson.build：

project('demo', 'c', version: '1.0',
        default_options: ['c_std=c11', 'warning_level=2'])

inc = include_directories('.')
lib = static_library('demo', 'lib.c', include_directories: inc)
demo_dep = declare_dependency(link_with: lib, include_directories: inc)
executable('prog', 'main.c', dependencies: demo_dep)

meson setup build-meson --buildtype=release
meson compile -C build-meson -j 4
./build-meson/prog

用 dependency 对象把链接库和 include 要求一起传递，避免消费者遗漏其中一项。优化与调试策略通常用 buildtype 或选项表达，不必把 -O2 硬编码到每个目标的 c_args，尤其要兼顾不同编译器。Meson 目标、Meson 依赖

已经 setup 的目录可以 reconfigure；更换编译器、交叉配置等关键环境时，独立构建目录有助于避免缓存混用。配置是否自动下载某些 fallback 依赖由项目和选项决定，不应把 dependency() 一律理解成包管理器安装命令。

增加生成头文件，验证完整的构建图

将 factor.txt 写为整数 2，新增下面的 generate.py。它只接受 1–100，避免把任意输入直接拼入 C 源码；输出放在命令指定的位置。

from pathlib import Path
import sys
source, output = map(Path, sys.argv[1:])
factor = int(source.read_text().strip())
if not 1 <= factor <= 100:
    raise SystemExit("factor must be in 1..100")
output.write_text(f"#define DEMO_FACTOR {factor}\n")

将 lib.c 与 main.c 分别替换为以下内容，lib.h 保持前面的声明。twice 沿用原函数名，但实际倍数现在由配置控制；例子仅以 21 调用，范围不会导致 int 溢出。

/* lib.c */
#include "lib.h"
#include "generated.h"
int twice(int x) { return x * DEMO_FACTOR; }

/* main.c */
#include "lib.h"
#include "generated.h"
int main(void) { return twice(21) == 21 * DEMO_FACTOR ? 0 : 1; }
生成头文件是编译输入，首次构建也必须有依赖边 factor.txt + generate.py 数据变化或生成器变化 generated.h 先由唯一生成规则产生 编译 lib.c 读取 DEMO_FACTOR 编译 main.c 同样读取 DEMO_FACTOR 编译器生成 .d 发生在编译时；缺失的头文件不能靠尚不存在的 .d 提前生成。

Make 显式声明首次构建依赖

在前面的 Makefile 追加下面规则，并在 clean 配方的删除列表中加入 generated.h：

PYTHON ?= python3
main.o lib.o: generated.h

generated.h: factor.txt generate.py
	$(PYTHON) generate.py factor.txt $@

两个对象都要依赖 generated.h，不能只让最终 prog 依赖它，否则并行构建可能先开始编译缺少头文件的源码。这里生成头文件是普通前置依赖：它改变后应重编译使用者。若误写成 order-only，就只保证先后顺序，不由此表达内容变化的重编译要求。

第一次成功编译后 .d 会进一步记录实际 include 关系，但首次构建的生成规则仍需要手工建边。生成多个输出时也要让它们归属于同一正确规则，避免多个任务同时写同一文件。

CMake 用唯一生成目标连接多个消费者

将以下片段加入已有 CMakeLists.txt，放在 demo 与 prog 都定义之后：

find_package(Python3 REQUIRED COMPONENTS Interpreter)
set(generated_header "${CMAKE_CURRENT_BINARY_DIR}/generated.h")
add_custom_command(
  OUTPUT "${generated_header}"
  COMMAND "${Python3_EXECUTABLE}"
          "${CMAKE_CURRENT_SOURCE_DIR}/generate.py"
          "${CMAKE_CURRENT_SOURCE_DIR}/factor.txt"
          "${generated_header}"
  DEPENDS generate.py factor.txt
  VERBATIM)
add_custom_target(generate_header DEPENDS "${generated_header}")
add_dependencies(demo generate_header)
add_dependencies(prog generate_header)
target_include_directories(demo PUBLIC "${CMAKE_CURRENT_BINARY_DIR}")

自定义命令拥有文件输出，公共生成目标保证两个消费者都在生成完成后编译；头文件内容变化后的细粒度重编译还由编译依赖扫描完成。VERBATIM 帮助正确传递路径参数，避免手工拼接 shell 引号。若生成器还产生必要副产物，应在适用版本下用 BYPRODUCTS 声明，不能把 Ninja 需要的输入藏在命令内部。CMake 自定义输出

Meson 把生成目标放入使用方的源列表

此步骤将原 meson.build 替换为：

project('demo', 'c', version: '1.0',
        default_options: ['c_std=c11', 'warning_level=2'])
python = import('python').find_installation('python3')
header = custom_target('generate_header',
  input: 'factor.txt', output: 'generated.h',
  command: [python, files('generate.py'), '@INPUT@', '@OUTPUT@'])
inc = include_directories('.')
lib = static_library('demo', ['lib.c', header], include_directories: inc)
demo_dep = declare_dependency(link_with: lib, include_directories: inc)
executable('prog', ['main.c', header], dependencies: demo_dep)

这里 include_directories('.') 包括对应的源码与构建目录，消费者源列表中的 header 表达生成顺序。generate.py 作为文件对象参与命令，数据 factor.txt 是显式输入，两者变化都能进入构建判断。不能只写一个指向未来生成目录的 include 路径，就期待构建系统推断生产者是谁。Meson 生成源码

用四种变化检查三套构建方案

三套实验建议分别使用独立的源码副本：Make 在源码目录生成 generated.h，而 CMake/Meson 在各自构建目录生成。若混用同一源码目录，C 的引号 include 可能优先找到 Make 遗留的头文件，使另一套构建使用了错误的生成结果。

变化预期动作发现的问题
全新目录、并行构建先生成，再编译两个对象，再链接首次依赖缺失
无任何修改再次构建没有生成或编译动作无条件运行导致无效工作
factor.txt 从 2 改为 3重新生成、重编译使用方、重新链接只表达先后而没表达变化
删除 generated.h自动重建输出并恢复成功构建输出未登记或依赖缓存掩盖问题

生成器本例每次真正执行都会更新时间戳，便于理解传播。如果采用“内容不变就不重写”来减少后续编译，Make 中还要处理输入比输出新的情况，避免每次都重新运行生成器；可以按项目需求设计 stamp 与真实输出的关系，不能只修改 Python 写入逻辑就认为增量行为已经完整。

少一条边，哪些产物会悄悄变旧？

生成头文件的内容变化需要分别使 main.o 和 lib.o 失效。删掉通往 main.o 的边，即使链接仍被另一条路径触发，main.o 也可能沿用旧宏值，形成混合版本产物。全新构建还需要这些边保证生成先于编译；增量正确与首次并行正确应分别验证。

正在呈现知识画面
少一条边，哪些产物会悄悄变旧？

构建图需要从变化输入传递到所有消费者。只让最终程序依赖生成头文件，不能代替对象文件的编译依赖。

pkg-config：查询已安装库的构建元数据

pkg-config --modversion zlib
pkg-config --cflags --libs zlib
pkg-config --static --libs zlib

.pc 文件告诉使用者头文件位置、库和相关依赖，并不负责安装库，也不保证运行时加载器能找到它。路径会随发行版、架构和安装前缀变化，不能固定成一个 /usr/lib64/pkgconfig。

一个示意的 demo.pc 内容如下，应保存为文本文件，不是当 shell 脚本执行：

prefix=/usr/local
libdir=${prefix}/lib
includedir=${prefix}/include

Name: demo
Description: Small example library
Version: 1.0
Libs: -L${libdir} -ldemo
Cflags: -I${includedir}

需要区分公开依赖与静态链接时所需的私有依赖，按情况填写 Requires、Requires.private、Libs.private。--static 查询更完整的依赖信息，并不单独强制链接器选用所有静态库。pkg-config 作者指南

CMake 中优先消费导入目标，避免只复制 ${ZLIB_LIBRARIES} 而漏掉目录或链接选项：

find_package(PkgConfig REQUIRED)
pkg_check_modules(ZLIB REQUIRED IMPORTED_TARGET zlib)
target_link_libraries(prog PRIVATE PkgConfig::ZLIB)

这段加入前面的 CMakeLists.txt 即可为 prog 附加依赖。若已有适用的 find_package(ZLIB) 导入目标，也可直接使用，无须强制经过 pkg-config。FindPkgConfig

交叉编译与可复现构建

构建时运行的代码生成器属于构建机器，最终程序属于目标机器。交叉编译要分别指定编译器、sysroot、工具与目标依赖搜索路径；不能误用宿主机 .pc 结果，再期待链接器自动纠正架构。

CMake toolchain 文件与 Meson cross file 用于描述这些环境。更完整的可复现性还涉及依赖版本、生成器、环境变量、路径嵌入与时间信息，并非用了某个构建系统就自动获得。

如何比较与验证

关注点应验证的行为
正确性干净构建、头文件变化、生成文件依赖都正确
增量效率无变化不重编译，局部变化只更新必要目标
并行多任务构建不出现偶发缺失文件或竞态
配置切换Debug、Release、不同编译器不混用旧产物
集成编译数据库、测试、安装与包元数据符合项目需要

构建快慢主要还取决于真实编译工作、依赖图粒度、缓存和执行器。Make 也有依赖图，CMake 也可生成 Ninja，不能用“命令式慢、声明式快”替代测量。

关键词：Make, CMake, Meson, Ninja, dependency graph, depfile, target, usage requirements, pkg-config, cross compilation, incremental build

链接预览

新窗口打开