Case For a Standardized Package Description Format for External C++ Libraries
summary
The ISO C++ survey shows most projects build third-party source with the project, which explains why build times remain a top pain point. The proposal argues for a build-system-agnostic package descriptor so package managers like Conan and vcpkg can expose transitive usage requirements rather than forcing source-vendoring or CMake-only solutions; current artifacts (CMake config, pkg-config, Libtool) are either tied to CMake or too flag-oriented, and C++ modules add more metadata to manage.
AI-written summary · about
chapters (36)
- 0:00Introduction
- 0:27Survey Results
- 2:27What does this mean
- 7:27Header only libraries
- 8:56Dependencies
- 12:22Modern C Make
- 14:17Targets
- 14:57Fine Logic
- 15:37Boost
- 16:35Encapsulation
- 16:55Binary Packages
- 17:50Config Files
- 18:37Scripting Language
- 19:54Open Issue
- 21:00Lip Tool
- 21:39Package Config
- 22:32Package Config Limitations
- 23:59Where We Are Today
- 25:11What is a Library
- 27:59The Way Forward
- 30:00Common Package Specification
- 32:12Litman
- 33:31Package Manager
- 34:31Package Configuration Files
- 36:19Package Independency Manager
- 37:13Package Config Files
- 40:02Package Description Files
- 41:18Repository Maintenance
- 43:21Summary
- 48:34Questions
- 49:19Where to start
- 49:56Is it extensible
- 51:11Is it transitive
- 52:41Why didnt standard proposals progress further
- 54:06Supporting multiple languages
- 56:17Collaboration
related talks
08mThe need for a package manager interface
01h 01mClean CMake for C++ (library) developers
09mC++ Package Manager
01h 31mISO C++ Standards Committee Panel Discussion
01h 07mC++20 Modules: The Packaging and Binary Redistribution Story
01h 02mCMake and the Future of C++
05mC++ Modules and Packages: Making Dreams Come True
52mCross plattform C++ development is challenging