On Mon, Mar 3, 2025 at 23:53 vspefs <vsp...@protonmail.com> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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 :(
>
> This option alone, I believe, could also offer some convenience to the
> general
> usage of modules.
>
> I have yet come up with a reference implementation! It should be quick
> work,
> though. Please share your ideas and suggestions.
>
> Best regards,
> vspefs


This is also a problem Fortran already solved. The -J option tells where to
write .mod files, and gfortran will search for .mod files in both the -J
directory as well as all -I directories.

I don’t mean to sound like a broken record, but it just seems to me like
there is a lot to be learned from the Fortran community.

Reply via email to