Document number:

ISO/IEC/JTC1/SC22/WG21/P2656R0

Date:

2022-10-13

Audience:

WG21

Reply-to:

René Ferdinand Rivera Morell - grafikrobot at gmail dot com - B2 Maintainer
Ben Craig - ben dot craig at gmail dot com

1. Abstract

We propose to publish an International Standard that specifies formats, processes, definitions, and so on, that facilitates the interoperation of the tools and systems that implement, and interface with, the C++ International Standard (ISO/IEC 14882).

2. Revision History

2.1. Revision 0 (October 2022)

Initial text.

3. Motivation

Interoperability is a challenge in today’s C++ ecosystem. At a time when the C++ language is advancing, the community is struggling to manage the challenges of the complexity and variability of the tools, technologies, and systems that make C++ possible. In the view of users the C++ ecosystem is fractured in ways that hinder its successful advancement.

The continued success of C++ is tied not solely to the language, but to the C++ ecosystem. The interoperability within that ecosystem is key to surmounting the challenges of further growth of the language for the benefit of users. It is therefore critical that we expand the specifications that WG21 produces to bring coherence to the C++ ecosystem.

Users should be able to mix and match their preferred build systems, compilers, linkers, package managers, static analyzers, runtime analyzers, debuggers, profilers, etc. without needing the tools to have vendor specific knowledge of each other. Vendors should be able to focus on direct tool improvements, rather than figuring out how to interact with yet another proprietary interface.

4. Scope

This new standard aims to clarify practice in a common way. It can contain various aspects of the C++ Ecosystem:

  1. Definitions : We will need a common language to refer to the many components and aspects of the ecosystem. With a shared understanding of components like: compilers, linkers, analyzers, debuggers, package managers, preprocessors, source files, object files, library files, shared library files, executables, and more, we can subsequently formulate specifications for them.

  2. Format Specifications : The tools that make up the ecosystem work by consuming and producing a variety of data in a variety of formats. We will need to specify those formats such that the tools and components can operate effectively.

  3. Operation Specifications : It’s not enough to know what the information the ecosystem contains, we also need to specify how that data is consumed and produced to aid in inter-operation of the variety of use cases in the C++ ecosystem.

This new standard will not:

  1. Mandate any single vendor tools : It is not a goal to seek single "blessed" tools in the ecosystem. We have a wide variety of good tools in the ecosystem. And we look forward to those tools cooperating with each other.

  2. Prohibit vendor extensions : It is not a goal to prevent vendor innovation in what the ecosystem tools can achieve. As such we welcome extensions and look towards the advancement that such extensions bring.

  3. Modify the C++ Language Standard : It is not a goal to alter, in any way, the C++ Language Standard. It is important that how we define the tools of the C++ ecosystem evolves independent of the language.

5. Goals

Like the C++ Language Standard this one will never be complete or finished. And it will take time and effort to provide coverage of the specifications needed to put together a good basic picture of the ecosystem. While the scope above defines an ideal completion, the goals for a first revision of this standard could include some modest items:

  1. Definitions

  2. Format Specifications :

    1. Build System ⇐⇒ Package Manager Interoperation

    2. File Names

5.1. Definitions

We will need some basic definitions as needed to circumscribe the specifications included in this first standard.

5.2. Build System ⇐⇒ Package Manager Interoperation

Specification of formats and operation of interoperability between build systems and package managers. Current and previous work on this:

  • P2673 Common Description Format for C++ Libraries and Packages [1]

  • The CppCon 2022 presentation "The Case For a Standardized Package Description Format", [2] prompted ongoing work to specify standard communication format between package managers and build systems.

  • P2577 C++ Modules Discovery in Prebuilt Library Releases [3]

  • P2536 Distributing C++ Module Libraries with dependencies json files. [4]

  • P2473 Distributing C++ Module Libraries. [5]

  • P1767 Packaging C++ Modules. [6]

  • libman, A Dependency Manager ➔ Build System Bridge [7]

  • P1313 Let’s Talk About Package Specification. [8]

  • P1177 Package Ecosystem Plan. [9]

5.3. File Names

Specification of a minimal set of file names understood, and for what they are understood, by the various tools in the ecosystem. Current and previous work on this:

  • P1838 Modules User-Facing Lexicon and File Extensions. [10]

  • P1177 Package Ecosystem Plan. [9]


1. Common Description Format for C++ Libraries and Packages (https://wg21.link/p2673r0)
2. CppCon 2022: The Case For a Standardized Package Description Format, Luis Caro Campos (https://cppcon.digital-medium.co.uk/session/2022/the-case-for-a-standardized-package-description-format/)
3. C++ Modules Discovery in Prebuilt Library Releases, Daniel Ruoso (https://github.com/cplusplus/papers/issues/1232)
4. Distributing C++ Module Libraries with dependencies json files. Olga Arkhipova (https://github.com/cplusplus/papers/issues/1199)
5. Distributing C++ Module Libraries. Daniel Ruoso (https://github.com/cplusplus/papers/issues/1131)
6. Packaging C++ Modules. Richard Smith (https://github.com/cplusplus/papers/issues/522)
7. libman, A Dependency Manager ➔ Build System Bridge Colby Pike (https://api.csswg.org/bikeshed/?force=1&url=https://raw.githubusercontent.com/vector-of-bool/libman/develop/data/spec.bs)
8. Let’s Talk About Package Specification. Matthew Woehlke (https://wg21.link/p1313)
9. Package Ecosystem Plan. René Ferdinand Rivera Morell (https://github.com/cplusplus/papers/issues/48)
10. Modules User-Facing Lexicon and File Extensions. Bryce Adelstein Lelbach, Boris Kolpackov (https://github.com/cplusplus/papers/issues/727)