原生构建与 C/C++ 依赖：分清描述、生成、执行和二进制包
C/C++ 项目常把 CMake、Ninja、编译器和包管理器统称为“构建工具”，随后出现“换成 Ninja 为什么依赖没解决”“用了 Conan 为什么还需要 CMake”这类错位问题。架构师先按责任分层，再谈速度和生态。
六篇文章
| 文章 | 所在层 | 核心问题 |
|---|---|---|
| GNU Make | 依赖描述与执行 | target、prerequisite、recipe、增量和并行怎样正确 |
| CMake | 上层构建描述与生成 | target、toolchain、preset、generator、install / test 怎样形成模型 |
| Ninja | 低层执行器 | 生成后的依赖边怎样高效执行，depfile 和日志怎样诊断 |
| Meson | 上层构建系统 | setup、Ninja backend、cross file、subproject / Wrap 怎样组织 |
| Conan 2 | C/C++ 二进制包管理 | profile、host / build context、lock、remote 和 package ID 怎样决定二进制图 |
| vcpkg | manifest 包管理 | baseline、triplet、registry、asset / binary cache 怎样约束恢复 |
先固定编译器、生成器与目标平台
记录 OS、CPU 架构、编译器及版本、SDK / sysroot、生成器、构建类型、toolchain 文件和包管理器来源。仅记录 cmake --version 不够，因为相同 CMake 配合不同编译器、generator、preset 和环境变量会生成不同执行图。
共同证据链
从干净 source tree 和独立 build directory 配置，不在源码目录混入历史产物。记录 configure 命令、preset、toolchain、generator、编译器身份和依赖来源。首次全量构建并运行测试，保存退出码、产物和必要诊断日志。
只修改一个输入，验证增量构建只重做正确目标。清理 build tree 与用户级包缓存时分层处理，删除前确认可重建。在 CI 或代表性平台用同一 preset / profile / manifest 重建并比较结果。
共同深水区
环境探测被缓存进 build tree，换编译器后继续复用旧配置。Debug / Release、静态 / 动态、runtime、ABI、triplet 或 profile 不一致，链接阶段才暴露。并行构建揭示了 Make 依赖边缺失，串行成功只是偶然顺序。
CMake 生成 Ninja 文件不意味着 Ninja 应由团队手写；执行器不能替代项目模型。Conan / vcpkg 二进制缓存来源、写权限或 package identity 不可信，热缓存掩盖错误工具链。cross file / toolchain / sysroot 包含本机绝对路径、内部地址或凭证，无法跨机器复用。
团队落地检查
每篇文章有最小项目、配置、构建、测试、增量、清理和失败定位证据。清楚说明工具所在层以及它不能替代什么，不用“更快”作为唯一选型理由。编译器、SDK、ABI、平台、生成器、profile / triplet 和二进制缓存进入架构取舍。
网络、代理、私有 remote / registry、凭证、许可证和包来源进入团队治理。构建问题进入生产构建机、正式交付或发布 SOP 后，沿部署运维与 18 制品交付家族继续定位，并保留客户端生成参数与服务端执行证据的关联。