Bloomberg's module requirements extend beyond a single build system

An import names a module, but the name does not tell a tool where the module lives or how to parse it. A build system controlling all dependency source can maintain that mapping internally. An application consuming installed packages needs the mapping to cross a boundary between independently built projects. C++20's module syntax does not by itself define that package interface.

Daniel Ruoso's P2409R0, dated July 12, describes this problem through Bloomberg's build environment. The paper reports tens of thousands of independent projects integrated into distribution snapshots of prebuilt artifacts. Its goal is to start an interoperability discussion, potentially leading to a technical report. It does not propose changing the language to mandate Bloomberg's build system.

I find this boundary important because C++'s compilation model is part of the cost of its abstractions. A feature that works inside one coordinated build still needs a usable package interface for separately maintained libraries. Installed headers and libraries already provide such a boundary, and modules need an account of the additional information consumers require.

Installed artifacts are an interface

Ruoso distinguishes builds that consume dependency sources from builds that consume dependency artifacts. In the first model, the build system understands how other parts of the codebase are built. In the second, projects expose intermediate artifacts for other projects to consume without knowledge of the producer's entire build process.

The paper uses the latter model to describe conventional development packages. A package may install headers, archives, and metadata such as pkg-config files. Consumers obtain the arguments needed for compilation and linking through that interface. They do not normally rerun the producer's build just to learn how to use the library.

An important distinction in the discussion is between producer flags and consumer requirements. The Cflags metadata describes arguments consumers need to reuse an interface. It is not simply a copy of everything used to compile the library implementation. Module interfaces add another parsing context whose requirements may differ from both the producer's private compilation and the importing application.

That context cannot be inferred merely from an ABI-compatible object file. An ABI permits linked code to agree about calls and representations. A compiler still needs declarations and semantic information during translation. If its only available module interface is a compiler-specific binary artifact, another otherwise ABI-compatible compiler may be unable to read it.

Discovery must not scan every installed module

The paper's first requirements concern bounded discovery cost. Given a module name, a tool should be able to test whether it exists and discover how to consume it with a fixed I/O cost independent of the total module population. A deterministic metadata filename is an example, not a mandated final design.

This matters when an installation contains more dependencies than one application uses. Scanning all available module source to construct a name map makes the cost depend on the environment's full contents. A developer opening a small project could pay for unrelated installed libraries. Ruoso argues that this is unrealistic for the artifact-consumption model.

Dependency discovery has a related ordering problem. Before parsing a module, a tool may need to discover the modules it imports. Making that information available through simpler metadata avoids parsing a dependency merely to find the next prerequisite for parsing it. The requirements ask for the external dependency graph without requiring full source parsing.

The paper also points out why searching source for an import token is insufficient. Preprocessing can participate in an import statement's contents, so discovery may require macro expansion and included files. Cheap metadata would expose the already-established dependency information without repeating that language processing for each consumer.

Compiler-specific interfaces do not settle interoperability

GCC 11.1's module documentation provides a concrete contemporary implementation model. Compiling an interface produces a compiled module interface that importers read. Imports must be built before their consumers. That implementation supports the language dependency, but the existence of a compiled artifact does not define a cross-compiler package convention.

P2409 asks for interoperable discovery across compilers and static-analysis tools on a platform. It separately asks for enough information to parse an interface. These are distinct requirements. A tool can know where a file is while lacking the preprocessor definitions or include paths needed to interpret it correctly.

The distinction also applies to caches. A compiler-specific binary interface can be a useful optimization when the consumer supports it. Treating it as the only available description, however, restricts consumers to that implementation. The paper asks for a way to recover the semantic interface without requiring knowledge of the original build system.

I prefer that requirement to assuming every consumer will use the producer's exact compiler. C++ projects already rely on platform ABI compatibility within defined limits. Module packaging should state which additional compatibility requirements it introduces instead of silently replacing the existing boundary with an opaque compiler artifact.

Development tools are consumers too

The paper treats compilation databases as an established way for external tools to observe a build. Editors and analyzers can obtain a translation unit's command without embedding themselves in the build system. Modules must preserve enough observable information for those tools to reproduce the translation's semantics.

An importing command alone may not contain the parsing settings for each independent module. The package interface must therefore make those settings discoverable alongside the module's files. Otherwise the build can succeed through private coordination while an editor receives an incomplete account of the program. That gap can affect a static analyzer using another compiler even when both compilers target the same platform ABI.

The final requirement asks for an interoperable representation cheaper to parse than original interface source. Ruoso distinguishes that goal from standardized discovery and notes that a universal solution across every platform may be unrealistic. The proposed scope begins where ABI interoperability is already expected. That gives tooling work a concrete compatibility boundary and leaves room for a technical report defining conventions within it.