Re: Naming flag for specifying the output file name for Binary Module Interface files

2022-12-07 Thread ben.boeckel via Gcc
On Wed, Dec 07, 2022 at 15:23:09 +, Jonathan Wakely wrote:
> I disagree. I can easily remember "module output" but I would have to check
> the manual every time to see if it's "std c++ module save file" or some
> other permutation of those words

I can say that in developing the CMake side of this, I had to keep going
back to the patch to remember the spelling.

--Ben


Re: Naming flag for specifying the output file name for Binary Module Interface files

2022-12-07 Thread ben.boeckel via Gcc
On Wed, Dec 07, 2022 at 16:18:00 +, Iain Sandoe wrote:
> I think it is reasonable to include c++ in the spelling, since other 
> languages supported by
> GCC (and clang in due course) have modules.

Especially given that Fortran doesn't necessarily have one module to
output; Fortran sources can contain many such modules (though they tend
to be looked up via include paths, so they are actually implicit builds
today; that may change if/when Fortran adopts P1689 as well).

--Ben


Re: Naming flag for specifying the output file name for Binary Module Interface files

2022-12-15 Thread ben.boeckel via Gcc
On Thu, Dec 15, 2022 at 07:37:35 +, Iain Sandoe wrote:
>  * I have patches for clang that implements the P1184 interface which
>  would allow a ‘module mapper’ to be used to discover  module name <->
>  pathname pairings.
> 
>  * The demand for the command line options we are discussing here is
>  coming from build systems folks who want to be able to specify
>  everything on the command line (i.e. from my understanding they do
>  not want to use a module mapper, but prefer dependency scanning).
> 
> So I think the two aspects are somewhat independent, I would expect
> the same build systems folks to want to be able to specify everything
> on the GCC command line too.

Note that it is particularly knowing the *output* module that is
important for distributed builds so that the dispatcher can know what
file(s) need to be sent and retrieved for a given command line. While
GCC's module mapper has the information, it is lacking any indication of
which might be output and input paths. With `-fmodule-output=`, the one
output is known and anything else known to the specified
`-fmodule-mapper=` (which must be understood by the dispatcher; I
suspect flat files will be the preferred mechanism here rather than a
socket or other fancy mechanism) can be assumed to be (potential;
ideally exact) inputs.

--Ben