The Importance of the C++ Build System Target Model
summary
Argues that a formal target model — concrete targets with usage requirements and transitive linking — fixes real pain: CMake moves from flag soup to exported targets, enabling reproducible consumption whether a library is built in-tree or preinstalled; C++20 modules require shipping BMI and compiler-context metadata (BMIs are compiler-specific and fragile); package managers duplicate 3rd‑party build recipes, while CPS (Common Package Specification) plus build-system-exported metadata could replace hundreds of brittle find scripts and speed dependency, CI and IDE setup.
AI-written summary · about
chapters (10)
- 0:00Introduction and concepts
- 2:38The problem of flag soup
- 7:39Historical build approaches
- 13:20Limitations of old tools
- 20:07The evolution of CMake
- 25:58Modern target mechanics
- 34:31Modules and C++20
- 38:11Cross-system comparisons
- 45:21Future with CPS
- 52:19Closing and Q&A
related talks
55mModern CMake for modular design
01h 04mBetter CMake: A World Tour of Build Systems - Better C++ Builds
01h 02mModern CMake Modules
01h 01mClean CMake for C++ (library) developers
01h 09mC++ Modules: Getting Started Today
01h 28mLink What You Include - Maintain a Coherent CMake Target Model
37mCross-Building Strategies in the Age of C++ Package Managers
01h 29mLibraries: A First Step Toward Standard C++ Dependency Management