RFC: A redesign of `-Mmodules` output

[Ben Boeckel]

On Tue, Mar 04, 2025 at 07:53:51 +0000, vspefs wrote:
> By the way, what's stop us from having compiler options like
> `g++ -Rgcm.cache -Rsomewhere/else/gcm.cache` to specify CMI repo path, like `-I`
> for include paths? It could be useful for projects with complex folder
> structure, as build tools like Make sometimes change current working directory,
> and so we need to locate CMIs in different folders.

Numerous :) . Consider these (non-exhaustive) problematic scenarios:

- incremental build, so some modules already exist, you find
  `imported.cmi`, but how do you know it is up-to-date?
- flag compatibility matters; if you find `imported.cmi`, but its flag
  set is incompatible, do you keep searching or give up?
- caching and distributed build tools now need to somehow encapsulate
  repository state into their hashes and send contents as necessary

> The mapping between module interface unit, module name, and expected CMI
> filename is still performed by the module mapper. But now when looking up a CMI,
> it goes to each repo in the list, in order, until it finds a CMI that matches
> and returns its full path. When producing a CMI, the CMI file is dumped to the
> first repo.

The mapper returns the path to where it wants the CMI; why second-guess
it by putting it somewhere it didn't specify? Same with lookup; the
mapper knows the full path it made the CMI at in the first place and
returns that. There should not need to be any searching involved at all.

> Ideally, all invocations concerning modules should have `-Rgcm.cache` as the
> first CMI repo. This way, all CMI producing calls remain deterministic, and
> behave same as before.

If you have a single build with both release and debug configurations,
they at least need to have separate repositories. Each executable should
as well because while `export module foo;` has to be unique in a
program, each executable could have their own `foo` module that doesn't
interact with others of the same name.

> To talk about its implementation, since GCC has already written a customed
> resolver for the built-in module mapper, all we need to do is adding a driver
> option, editing the existing c++tools/resolver.cc, and implementing the option
> logic.

Sure, the implementation isn't hard. It's all the knock-on effects that
are hard to deal with.

> This could make Make-based build systems really work. The Makefile rules
> proposed in this RFC make sure CMIs are built before used, and this `-R` flag
> offers big-project-ready module lookup mechanics, if we just ignore the multiple
> CMIs problem for now :(

IMO, simple `%.o: %.cxx` build systems are dead with C++ modules. One
just needs to have a comprehensive understanding of the source files
involved and the relationship between groups of them to get it right.

> This option alone, I believe, could also offer some convenience to the general
> usage of modules.

I believe the only place for such things is in "make this one file I
have" use cases. Projects should use proper infrastructure that handles
modules correctly.

--Ben