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
