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

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

[David Blaikie]

Over in https://reviews.llvm.org/D137059 we're discussing the naming
of a clang flag - would be good to have it be consistent with GCC.

The functionality is to name the BMI (.pcm in Clang's parlance) output
file when compiling a C++20 module.

Current proposal is to use `-fsave-std-cxx-module-file=` which is
certainly precise, but maybe a bit verbose. Clang has some other flags
related to modules that skip the std/cxx parts, and are just
`-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.

Do GCC folks have any veto votes (is the currently proposed name
especially objectionable/wouldn't be acceptable in GCC) or preferences
(suggestions to add to the pool)?

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

[Nathan Sidwell]

On 12/6/22 16:03, David Blaikie wrote:
> Over in https://reviews.llvm.org/D137059 we're discussing the naming
> of a clang flag - would be good to have it be consistent with GCC.
> 
> The functionality is to name the BMI (.pcm in Clang's parlance) output
> file when compiling a C++20 module.
> 
> Current proposal is to use `-fsave-std-cxx-module-file=` which is
> certainly precise, but maybe a bit verbose. Clang has some other flags
> related to modules that skip the std/cxx parts, and are just
> `-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.
> 
> Do GCC folks have any veto votes (is the currently proposed name
> especially objectionable/wouldn't be acceptable in GCC) or preferences
> (suggestions to add to the pool)?

I think the suggested option name is problematic for a number of additional reasons:

1) 'save' -- does it *cause* the bmi to be saved, or is that actually controlled 
by other options?  (I suspect the latter)

2) 'std' -- why is this there.  There's only one C++ std, with different 
variants thereof being temporally selectable.

3) 'cxx' -- why not 'c++'?  Let's not let this transliteration of + to x get 
into the options -- it hasn't in '-std=c++20' for example.

Might I suggest something more like '-fmodule-output='?  That collates nicely 
with other -fmodule-$FOO options, and the 'output' part is similar to the 
mnemonic '-o' for the regular output file naming.  (Incidentally, as clang 
treats the BMI as a step in the compilation pipeline, what do you do if you just 
want compilation to produce the BMI and no assembly artifact?  Does '-o' name 
the BMI in that case?)

nathan

-- 
Nathan Sidwell

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

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On Wed, 7 Dec 2022, 00:36 Nathan Sidwell via Gcc, <gcc@gcc.gnu.org> wrote:

> On 12/6/22 16:03, David Blaikie wrote:
> > Over in https://reviews.llvm.org/D137059 we're discussing the naming
> > of a clang flag - would be good to have it be consistent with GCC.
> >
> > The functionality is to name the BMI (.pcm in Clang's parlance) output
> > file when compiling a C++20 module.
> >
> > Current proposal is to use `-fsave-std-cxx-module-file=` which is
> > certainly precise, but maybe a bit verbose. Clang has some other flags
> > related to modules that skip the std/cxx parts, and are just
> > `-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.
> >
> > Do GCC folks have any veto votes (is the currently proposed name
> > especially objectionable/wouldn't be acceptable in GCC) or preferences
> > (suggestions to add to the pool)?
>
> I think the suggested option name is problematic for a number of
> additional reasons:
>
> 1) 'save' -- does it *cause* the bmi to be saved, or is that actually
> controlled
> by other options?  (I suspect the latter)
>
> 2) 'std' -- why is this there.  There's only one C++ std, with different
> variants thereof being temporally selectable.
>
> 3) 'cxx' -- why not 'c++'?  Let's not let this transliteration of + to x
> get
> into the options -- it hasn't in '-std=c++20' for example.
>
> Might I suggest something more like '-fmodule-output='?  That collates
> nicely
> with other -fmodule-$FOO options, and the 'output' part is similar to the
> mnemonic '-o' for the regular output file naming.
>

That's also much shorter and easier to remember than the five(!) words in
the original suggestion.

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

[chuanqi.xcq]

[-- Attachment #1: Type: text/plain, Size: 4988 bytes --]

Hi Nathan,
> 1) 'save' -- does it *cause* the bmi to be saved, or is that actually controlled 
by other options? (I suspect the latter)
Yes, it causes the bmi to be saved. In fact, when we add `-save-temps` option in clang and we compile a module unit, we'll see the preprocessed output, the bmi, the LLVM IR and the assembly code. So the semantics of the option `-fsave-std-cxx-module-file=` is to save the bmi to the specified output.
> 2) 'std' -- why is this there. There's only one C++ std, with different 
variants thereof being temporally selectable.
Since in clang we have clang c++ modules extension. It is not std one. And we have objective C modules in clang too. So we said `std-cxx`.
> 3) 'cxx' -- why not 'c++'? Let's not let this transliteration of + to x get 
into the options -- it hasn't in '-std=c++20' for example.
`c++` should be good advice.
> Might I suggest something more like '-fmodule-output='? That collates nicely with other -fmodule-$FOO options, and the 'output' part is similar to the mnemonic '-o' for the regular output file naming.
My previous concern was there were tons of `-fmodule-*` options in clang, which are not standard c++ modules. So I was afraid the name `-fmodule-output` may be confusing.
So I proposed `-fsave-std-cxx-module-file=`. But I didn't recognize we need to keep the option consistency between gcc and clang until Iain mentioned it.
It is obviously redundant for gcc to keep the `-std-cxx` prefix in the name. Personally, I feel the clearity of the option name is more important than the length.
Since I think such flags will be mainly used by build systems/build scripts so such flags wouldn't be typed frequently.
But command line interface consistency is very important too. I know tools writer will hate to write tons of codes like:
```
if compiler == gcc
 ...
elif compiler == clang
 ...
```
So I think the conclusion may be:
(1) If gcc can tolerate the lengthy `-fsave-std-c++-module-file=` name, it would be best for clang.
(2) If (1) is not acceptable and we love to keep the command line consistency, I think clang can use '-fmodule-output=' as long as we make it clear in the document. It will be confusing but it may be the cost clang need to pay for the extension (so I'll vote against strongly if someone want to add some other extensions)
>  (Incidentally, as clang 
treats the BMI as a step in the compilation pipeline, what do you do if you just 
want compilation to produce the BMI and no assembly artifact? Does '-o' name 
the BMI in that case?)
In this case, we can use `--precompile` option in the command line. For example, we can compile HelloWorld in clang in the following command lines now:
```
$ clang++ -std=c++20 Hello.cppm --precompile -o Hello.pcm
$ clang++ -std=c++20 -fprebuilt-module-path=. Hello.pcm -c -o Hello.o
```
If you are interested, you can take a look at: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#quick-start
Thanks,
Chuanqi
------------------------------------------------------------------
From:Nathan Sidwell <nathan@acm.org>
Send Time:2022年12月7日(星期三) 08:35
To:David Blaikie <dblaikie@gmail.com>; gcc Mailing List <gcc@gcc.gnu.org>; Iain Sandoe <iain@sandoe.co.uk>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>
Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
On 12/6/22 16:03, David Blaikie wrote:
> Over in https://reviews.llvm.org/D137059 we're discussing the naming
> of a clang flag - would be good to have it be consistent with GCC.
> 
> The functionality is to name the BMI (.pcm in Clang's parlance) output
> file when compiling a C++20 module.
> 
> Current proposal is to use `-fsave-std-cxx-module-file=` which is
> certainly precise, but maybe a bit verbose. Clang has some other flags
> related to modules that skip the std/cxx parts, and are just
> `-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.
> 
> Do GCC folks have any veto votes (is the currently proposed name
> especially objectionable/wouldn't be acceptable in GCC) or preferences
> (suggestions to add to the pool)?
I think the suggested option name is problematic for a number of additional reasons:
1) 'save' -- does it *cause* the bmi to be saved, or is that actually controlled 
by other options? (I suspect the latter)
2) 'std' -- why is this there. There's only one C++ std, with different 
variants thereof being temporally selectable.
3) 'cxx' -- why not 'c++'? Let's not let this transliteration of + to x get 
into the options -- it hasn't in '-std=c++20' for example.
Might I suggest something more like '-fmodule-output='? That collates nicely 
with other -fmodule-$FOO options, and the 'output' part is similar to the 
mnemonic '-o' for the regular output file naming. (Incidentally, as clang 
treats the BMI as a step in the compilation pipeline, what do you do if you just 
want compilation to produce the BMI and no assembly artifact? Does '-o' name 
the BMI in that case?)
nathan
-- 
Nathan Sidwell

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

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

On Wed, 7 Dec 2022, 02:30 chuanqi.xcq via Gcc, <gcc@gcc.gnu.org> wrote:

> Hi Nathan,
> > 1) 'save' -- does it *cause* the bmi to be saved, or is that actually
> controlled
> by other options? (I suspect the latter)
> Yes, it causes the bmi to be saved. In fact, when we add `-save-temps`
> option in clang and we compile a module unit, we'll see the preprocessed
> output, the bmi, the LLVM IR and the assembly code. So the semantics of the
> option `-fsave-std-cxx-module-file=` is to save the bmi to the specified
> output.
> > 2) 'std' -- why is this there. There's only one C++ std, with different
> variants thereof being temporally selectable.
> Since in clang we have clang c++ modules extension. It is not std one. And
> we have objective C modules in clang too. So we said `std-cxx`.
> > 3) 'cxx' -- why not 'c++'? Let's not let this transliteration of + to x
> get
> into the options -- it hasn't in '-std=c++20' for example.
> `c++` should be good advice.
> > Might I suggest something more like '-fmodule-output='? That collates
> nicely with other -fmodule-$FOO options, and the 'output' part is similar
> to the mnemonic '-o' for the regular output file naming.
> My previous concern was there were tons of `-fmodule-*` options in clang,
> which are not standard c++ modules. So I was afraid the name
> `-fmodule-output` may be confusing.
> So I proposed `-fsave-std-cxx-module-file=`. But I didn't recognize we
> need to keep the option consistency between gcc and clang until Iain
> mentioned it.
> It is obviously redundant for gcc to keep the `-std-cxx` prefix in the
> name. Personally, I feel the clearity of the option name is more important
> than the length.
>

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

And if the flag is not consistent between clang and GCC that's even worse.

Since I think such flags will be mainly used by build systems/build scripts
> so such flags wouldn't be typed frequently.
> But command line interface consistency is very important too. I know tools
> writer will hate to write tons of codes like:
> ```
> if compiler == gcc
>  ...
> elif compiler == clang
>  ...
> ```
> So I think the conclusion may be:
> (1) If gcc can tolerate the lengthy `-fsave-std-c++-module-file=` name, it
> would be best for clang.
>

IMHO that's unacceptable for GCC.


(2) If (1) is not acceptable and we love to keep the command line
> consistency, I think clang can use '-fmodule-output=' as long as we make it
> clear in the document. It will be confusing but it may be the cost clang
> need to pay for the extension (so I'll vote against strongly if someone
> want to add some other extensions)
>

Given that C++20 modules are in an ISO standard and clang modules aren't, I
think it's right that the "simple" name refers to C++20 modules, without
requiring "std-c++-modules". It also seems right that the difficulty of
distinguishing clang modules from std modules should be dealt with by
clang, not by other compilers.

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

[ben.boeckel]

On Wed, Dec 07, 2022 at 15:23:09 +0000, 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

[Iain Sandoe]

Hi Folks,

> On 7 Dec 2022, at 15:45, ben.boeckel via Gcc <gcc@gcc.gnu.org> wrote:
> 
> On Wed, Dec 07, 2022 at 15:23:09 +0000, 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

For my 0.02GBP, I had previously suggested “-fc++-module-file[name=]“

In review, that  was felt to be possibly unwieldy if there was a default (e.g. that the
module BMI takes the basename and appends .gcm/pcm), but I will offer the suggestion
a second time ;)

I think it is reasonable to include c++ in the spelling, since other languages supported by
GCC (and clang in due course) have modules.

Iain

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

[ben.boeckel]

On Wed, Dec 07, 2022 at 16:18:00 +0000, 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

[Nathan Sidwell]

On 12/7/22 10:23, Jonathan Wakely wrote:
> 
> 
> On Wed, 7 Dec 2022, 02:30 chuanqi.xcq via Gcc, <gcc@gcc.gnu.org 
> <mailto:gcc@gcc.gnu.org>> wrote:
\
> 
>     (2) If (1) is not acceptable and we love to keep the command line
>     consistency, I think clang can use '-fmodule-output=' as long as we make it
>     clear in the document. It will be confusing but it may be the cost clang
>     need to pay for the extension (so I'll vote against strongly if someone want
>     to add some other extensions)
> 
> 
> Given that C++20 modules are in an ISO standard and clang modules aren't, I 
> think it's right that the "simple" name refers to C++20 modules, without 
> requiring "std-c++-modules". It also seems right that the difficulty of 
> distinguishing clang modules from std modules should be dealt with by clang, not 
> by other compilers.

Wait, why does clang want different options to specify the name of the 
clang-module file vs a C++ module file?  It's only in one mode at a time isn't 
it?  And that mode is controlled by other options.  It cannot generate both in a 
single compilation, right?

nathan

-- 
Nathan Sidwell

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

[Nathan Sidwell]

On 12/7/22 11:18, 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.

I disagree (about the reasonableness part).  Other languages have modules, true, 
but if they want to name the output file, why not have the same option spelling?

I.e. why are we considering:

    $compiler -fc++-module-file=bob foo.cc
    $compiler -ffortran-module-file=bob foo.f77

The language is being selected implicitly by the file suffix (or explictly via 
-X$lang).  There's no reason for some other option controlling an aspect of the 
compilation to rename the language.  We don't do it for language-specific 
warning options, and similar.  (i.e. no -f[no-]c++-type-aliasing vs 
-fc-type-aliasing, nor -Wc++-extra vs -Wc-extra[*]

nathan

[*] I'll grant there is -Weffective-c++, but that's somewhat out of date now.
-- 
Nathan Sidwell

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

[Iain Sandoe]

> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc <gcc@gcc.gnu.org> wrote:
> 
> On 12/7/22 11:18, 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.
> 
> I disagree (about the reasonableness part).  Other languages have modules, true, but if they want to name the output file, why not have the same option spelling?
> 
> I.e. why are we considering:
> 
>   $compiler -fc++-module-file=bob foo.cc
>   $compiler -ffortran-module-file=bob foo.f77
> 
> The language is being selected implicitly by the file suffix (or explictly via -X$lang).  There's no reason for some other option controlling an aspect of the compilation to rename the language.  We don't do it for language-specific warning options, and similar.  (i.e. no -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs -Wc-extra[*]

Fair points.

Unfortunately (in case it has not already been mentioned in this thread) ‘-fmodule-file=‘ is already taken and it means an input, not an output.  So, whatever we choose it needs to be distinct from that.

Iain

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

[Nathan Sidwell]

On 12/7/22 11:58, Iain Sandoe wrote:
> 
> 
>> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> On 12/7/22 11:18, 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.
>>
>> I disagree (about the reasonableness part).  Other languages have modules, true, but if they want to name the output file, why not have the same option spelling?
>>
>> I.e. why are we considering:
>>
>>    $compiler -fc++-module-file=bob foo.cc
>>    $compiler -ffortran-module-file=bob foo.f77
>>
>> The language is being selected implicitly by the file suffix (or explictly via -X$lang).  There's no reason for some other option controlling an aspect of the compilation to rename the language.  We don't do it for language-specific warning options, and similar.  (i.e. no -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs -Wc-extra[*]
> 
> Fair points.
> 
> Unfortunately (in case it has not already been mentioned in this thread) ‘-fmodule-file=‘ is already taken and it means an input, not an output.  So, whatever we choose it needs to be distinct from that.

Yes, that's why I suggested -fmodule-output=

nathan

-- 
Nathan Sidwell

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

[chuanqi.xcq]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here~
Thanks,
Chuanqi
------------------------------------------------------------------
From:Nathan Sidwell <nathan@acm.org>
Send Time:2022年12月8日(星期四) 01:00
To:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>
Cc:Jonathan Wakely <jwakely.gcc@gmail.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>; David Blaikie <dblaikie@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>
Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
On 12/7/22 11:58, Iain Sandoe wrote:
> 
> 
>> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> On 12/7/22 11:18, 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.
>>
>> I disagree (about the reasonableness part). Other languages have modules, true, but if they want to name the output file, why not have the same option spelling?
>>
>> I.e. why are we considering:
>>
>> $compiler -fc++-module-file=bob foo.cc
>> $compiler -ffortran-module-file=bob foo.f77
>>
>> The language is being selected implicitly by the file suffix (or explictly via -X$lang). There's no reason for some other option controlling an aspect of the compilation to rename the language. We don't do it for language-specific warning options, and similar. (i.e. no -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs -Wc-extra[*]
> 
> Fair points.
> 
> Unfortunately (in case it has not already been mentioned in this thread) ‘-fmodule-file=‘ is already taken and it means an input, not an output. So, whatever we choose it needs to be distinct from that.
Yes, that's why I suggested -fmodule-output=
nathan
-- 
Nathan Sidwell

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

[Iain Sandoe]

Hello all.

> On 9 Dec 2022, at 01:58, chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
> 
> It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here

So FAOD (after this discussion) Chuanqi's current patchset implements the following in clang:

-fmodule-output

  - this causes the BMI to be saved in the CWG with the basename of the source file and a suffix of .pcm.

-fmodule-output=<path>

 - this causes the BMI to be saved at the path specified.

===

These facilities support build systems that do not use the P1184 interface to map between module names and paths.

cheers
Iain

> 
> Thanks,
> Chuanqi
> ------------------------------------------------------------------
> From:Nathan Sidwell <nathan@acm.org>
> Send Time:2022年12月8日(星期四) 01:00
> To:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>
> Cc:Jonathan Wakely <jwakely.gcc@gmail.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>; David Blaikie <dblaikie@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>
> Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
> 
> On 12/7/22 11:58, Iain Sandoe wrote:
> > 
> > 
> >> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc <gcc@gcc.gnu.org> wrote:
> >>
> >> On 12/7/22 11:18, 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.
> >>
> >> I disagree (about the reasonableness part).  Other languages have modules, true, but if they want to name the output file, why not have the same option spelling?
> >>
> >> I.e. why are we considering:
> >>
> >>    $compiler -fc++-module-file=bob foo.cc
> >>    $compiler -ffortran-module-file=bob foo.f77
> >>
> >> The language is being selected implicitly by the file suffix (or explictly via -X$lang).  There's no reason for some other option controlling an aspect of the compilation to rename the language.  We don't do it for language-specific warning options, and similar.  (i.e. no -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs -Wc-extra[*]
> > 
> > Fair points.
> > 
> > Unfortunately (in case it has not already been mentioned in this thread) ‘-fmodule-file=‘ is already taken and it means an input, not an output.  So, whatever we choose it needs to be distinct from that.
> 
> Yes, that's why I suggested -fmodule-output=
> 
> nathan
> 
> -- 
> Nathan Sidwell

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

[David Blaikie]

Thanks Iain for the summary/thanks everyone for the discussion!

On Fri, Dec 9, 2022 at 9:33 AM Iain Sandoe <iain@sandoe.co.uk> wrote:
>
> Hello all.
>
> > On 9 Dec 2022, at 01:58, chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
> >
> > It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here
>
> So FAOD (after this discussion) Chuanqi's current patchset implements the following in clang:
>
> -fmodule-output
>
>   - this causes the BMI to be saved in the CWG with the basename of the source file and a suffix of .pcm.
>
> -fmodule-output=<path>
>
>  - this causes the BMI to be saved at the path specified.
>
> ===
>
> These facilities support build systems that do not use the P1184 interface to map between module names and paths.
>
> cheers
> Iain
>
> >
> > Thanks,
> > Chuanqi
> > ------------------------------------------------------------------
> > From:Nathan Sidwell <nathan@acm.org>
> > Send Time:2022年12月8日(星期四) 01:00
> > To:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>
> > Cc:Jonathan Wakely <jwakely.gcc@gmail.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>; David Blaikie <dblaikie@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>
> > Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
> >
> > On 12/7/22 11:58, Iain Sandoe wrote:
> > >
> > >
> > >> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc <gcc@gcc.gnu.org> wrote:
> > >>
> > >> On 12/7/22 11:18, 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.
> > >>
> > >> I disagree (about the reasonableness part).  Other languages have modules, true, but if they want to name the output file, why not have the same option spelling?
> > >>
> > >> I.e. why are we considering:
> > >>
> > >>    $compiler -fc++-module-file=bob foo.cc
> > >>    $compiler -ffortran-module-file=bob foo.f77
> > >>
> > >> The language is being selected implicitly by the file suffix (or explictly via -X$lang).  There's no reason for some other option controlling an aspect of the compilation to rename the language.  We don't do it for language-specific warning options, and similar.  (i.e. no -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs -Wc-extra[*]
> > >
> > > Fair points.
> > >
> > > Unfortunately (in case it has not already been mentioned in this thread) ‘-fmodule-file=‘ is already taken and it means an input, not an output.  So, whatever we choose it needs to be distinct from that.
> >
> > Yes, that's why I suggested -fmodule-output=
> >
> > nathan
> >
> > --
> > Nathan Sidwell
>

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

[Nathan Sidwell]

On 12/9/22 12:33, Iain Sandoe wrote:
> Hello all.
> 
>> On 9 Dec 2022, at 01:58, chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
>>
>> It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here
> 
> So FAOD (after this discussion) Chuanqi's current patchset implements the following in clang:
> 
> -fmodule-output
> 
>    - this causes the BMI to be saved in the CWG with the basename of the source file and a suffix of .pcm.
> 
> -fmodule-output=<path>
> 
>   - this causes the BMI to be saved at the path specified.
> 

1) Are these flags silently ignored, if no module output is to be generated? Or 
is some kind of diagnostic generated?

2) what happens if you specify both -- do you get two outputs, a diagnostic, or 
is one silently selected?

3) What is the behaviour if compilation fails?  Does nothing happen to the file 
indicated (potentially leaving an older version there), or does the equivalent 
of 'rm -f $MODULE.pcm' happen?

nathan

-- 
Nathan Sidwell

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

[chuanqi.xcq]

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

Hi Nathan,
> 1) Are these flags silently ignored, if no module output is to be generated? Or is some kind of diagnostic generated?
Currently, clang will generate the unused-command-line-argument warning for this case:
```
argument unused during compilation: '-fmodule-output' [-Wunused-command-line-argument]
```
> 2) what happens if you specify both -- do you get two outputs, a diagnostic, or 
is one silently selected?
If someone specify both `-fmodule-output` and `-fmodule-output=/path`,
the `-fmodule-output=/path` will be selected always no matter what the order is.
And if multiple `-fmodule-output=/path` are specified, the last one will be selected.
> 3) What is the behaviour if compilation fails? Does nothing happen to the file 
indicated (potentially leaving an older version there), or does the equivalent 
of 'rm -f $MODULE.pcm' happen?
The module file will be deleted. The behavior is the same with `-o`.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Nathan Sidwell <nathan@acm.org>
Send Time:2022年12月12日(星期一) 22:30
To:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>
Cc:Nathan Sidwell <nathanmsidwell@gmail.com>; Jonathan Wakely <jwakely.gcc@gmail.com>; David Blaikie <dblaikie@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>
Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
On 12/9/22 12:33, Iain Sandoe wrote:
> Hello all.
> 
>> On 9 Dec 2022, at 01:58, chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
>>
>> It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here
> 
> So FAOD (after this discussion) Chuanqi's current patchset implements the following in clang:
> 
> -fmodule-output
> 
> - this causes the BMI to be saved in the CWG with the basename of the source file and a suffix of .pcm.
> 
> -fmodule-output=<path>
> 
> - this causes the BMI to be saved at the path specified.
> 
1) Are these flags silently ignored, if no module output is to be generated? Or 
is some kind of diagnostic generated?
2) what happens if you specify both -- do you get two outputs, a diagnostic, or 
is one silently selected?
3) What is the behaviour if compilation fails? Does nothing happen to the file 
indicated (potentially leaving an older version there), or does the equivalent 
of 'rm -f $MODULE.pcm' happen?
nathan
-- 
Nathan Sidwell

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

[David Blaikie]

I think Nathan might've been asking not only about what currently
happens, but what we think should happen?

On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
>
> Hi Nathan,
>
> > 1) Are these flags silently ignored, if no module output is to be generated? Or  is some kind of diagnostic generated?
>
> Currently, clang will generate the unused-command-line-argument warning for this case:
>
> ```
> argument unused during compilation: '-fmodule-output' [-Wunused-command-line-argument]
> ```

Is that consistent with `-o`? (I assume so, but don't know - I guess
there aren't many cases where `-o` is unused (maybe `-fsyntax-only`),
so that behavior might be a bit less well specified)

> > 2) what happens if you specify both -- do you get two outputs, a diagnostic, or
> is one silently selected?
>
> If someone specify both `-fmodule-output` and `-fmodule-output=/path`,
> the `-fmodule-output=/path` will be selected always no matter what the order is.

This seems surprising/possibly wrong to me - do we have precedent from
other flags to draw from?

> And if multiple `-fmodule-output=/path` are specified, the last one will be selected.
>
> > 3) What is the behaviour if compilation fails?  Does nothing happen to the file
> indicated (potentially leaving an older version there), or does the equivalent
> of 'rm -f $MODULE.pcm' happen?
>
> The module file will be deleted. The behavior is the same with `-o`.
>
> Thanks,
> Chuanqi
>
>
> ------------------------------------------------------------------
> From:Nathan Sidwell <nathan@acm.org>
> Send Time:2022年12月12日(星期一) 22:30
> To:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>
> Cc:Nathan Sidwell <nathanmsidwell@gmail.com>; Jonathan Wakely <jwakely.gcc@gmail.com>; David Blaikie <dblaikie@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>
> Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
>
> On 12/9/22 12:33, Iain Sandoe wrote:
> > Hello all.
> >
> >> On 9 Dec 2022, at 01:58, chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
> >>
> >> It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here
> >
> > So FAOD (after this discussion) Chuanqi's current patchset implements the following in clang:
> >
> > -fmodule-output
> >
> >    - this causes the BMI to be saved in the CWG with the basename of the source file and a suffix of .pcm.
> >
> > -fmodule-output=<path>
> >
> >   - this causes the BMI to be saved at the path specified.
> >
>
> 1) Are these flags silently ignored, if no module output is to be generated? Or
> is some kind of diagnostic generated?
>
> 2) what happens if you specify both -- do you get two outputs, a diagnostic, or
> is one silently selected?
>
> 3) What is the behaviour if compilation fails?  Does nothing happen to the file
> indicated (potentially leaving an older version there), or does the equivalent
> of 'rm -f $MODULE.pcm' happen?
>
> nathan
>
> --
> Nathan Sidwell
>
>

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

[chuanqi.xcq]

[-- Attachment #1: Type: text/plain, Size: 4780 bytes --]

Hi David,
> I think Nathan might've been asking not only about what currently
happens, but what we think should happen?
Yes.
> Is that consistent with `-o`? (I assume so, but don't know - I guess
there aren't many cases where `-o` is unused (maybe `-fsyntax-only`),
so that behavior might be a bit less well specified)
`-o` wouldn't emit a warning if it is not used. (with `-fsyntax-only` for example).
Since we want to make the behavior of `-fmodule-output` to be consistent with `-o`.
I've changed the behavior in https://reviews.llvm.org/D140001.
> This seems surprising/possibly wrong to me - do we have precedent from
other flags to draw from?
I feel it makes sense since `-fmodule-output=` will provide more information than `-fmodule-output`.
So it is naturally to me that `-fmodule-output=` has higher priority.
For examples, I don't enumerate all the flags but I find the following cases in minutes:
- `-fpack-struct=` has higher priority than `-fpack-struct`.
- `-fsave-optimization-record=` has higher priority than `-fsave-optimization-record=`.
- `-ftime-report=` has higher priority than `-ftime-report`.
- `-ftime-trace=` has higher priority than `-ftime-trace`.
So I think the bahavior should be correct.
Thanks,
Chuanqi
------------------------------------------------------------------
From:David Blaikie <dblaikie@gmail.com>
Send Time:2022年12月13日(星期二) 23:56
To:chuanqi.xcq <yedeng.yd@linux.alibaba.com>
Cc:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>; Nathan Sidwell <nathanmsidwell@gmail.com>; Jonathan Wakely <jwakely.gcc@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>
Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
I think Nathan might've been asking not only about what currently
happens, but what we think should happen?
On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
>
> Hi Nathan,
>
> > 1) Are these flags silently ignored, if no module output is to be generated? Or is some kind of diagnostic generated?
>
> Currently, clang will generate the unused-command-line-argument warning for this case:
>
> ```
> argument unused during compilation: '-fmodule-output' [-Wunused-command-line-argument]
> ```
Is that consistent with `-o`? (I assume so, but don't know - I guess
there aren't many cases where `-o` is unused (maybe `-fsyntax-only`),
so that behavior might be a bit less well specified)
> > 2) what happens if you specify both -- do you get two outputs, a diagnostic, or
> is one silently selected?
>
> If someone specify both `-fmodule-output` and `-fmodule-output=/path`,
> the `-fmodule-output=/path` will be selected always no matter what the order is.
This seems surprising/possibly wrong to me - do we have precedent from
other flags to draw from?
> And if multiple `-fmodule-output=/path` are specified, the last one will be selected.
>
> > 3) What is the behaviour if compilation fails? Does nothing happen to the file
> indicated (potentially leaving an older version there), or does the equivalent
> of 'rm -f $MODULE.pcm' happen?
>
> The module file will be deleted. The behavior is the same with `-o`.
>
> Thanks,
> Chuanqi
>
>
> ------------------------------------------------------------------
> From:Nathan Sidwell <nathan@acm.org>
> Send Time:2022年12月12日(星期一) 22:30
> To:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>
> Cc:Nathan Sidwell <nathanmsidwell@gmail.com>; Jonathan Wakely <jwakely.gcc@gmail.com>; David Blaikie <dblaikie@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>
> Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
>
> On 12/9/22 12:33, Iain Sandoe wrote:
> > Hello all.
> >
> >> On 9 Dec 2022, at 01:58, chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
> >>
> >> It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here
> >
> > So FAOD (after this discussion) Chuanqi's current patchset implements the following in clang:
> >
> > -fmodule-output
> >
> > - this causes the BMI to be saved in the CWG with the basename of the source file and a suffix of .pcm.
> >
> > -fmodule-output=<path>
> >
> > - this causes the BMI to be saved at the path specified.
> >
>
> 1) Are these flags silently ignored, if no module output is to be generated? Or
> is some kind of diagnostic generated?
>
> 2) what happens if you specify both -- do you get two outputs, a diagnostic, or
> is one silently selected?
>
> 3) What is the behaviour if compilation fails? Does nothing happen to the file
> indicated (potentially leaving an older version there), or does the equivalent
> of 'rm -f $MODULE.pcm' happen?
>
> nathan
>
> --
> Nathan Sidwell
>
>

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

[David Blaikie]

On Wed, Dec 14, 2022 at 1:56 AM chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
>
> Hi David,
>
> > I think Nathan might've been asking not only about what currently
> happens, but what we think should happen?
>
> Yes.
>
> > Is that consistent with `-o`? (I assume so, but don't know - I guess
> there aren't many cases where `-o` is unused (maybe `-fsyntax-only`),
> so that behavior might be a bit less well specified)
>
> `-o` wouldn't emit a warning if it is not used. (with `-fsyntax-only` for example).
> Since we want to make the behavior of `-fmodule-output` to be consistent with `-o`.
> I've changed the behavior in https://reviews.llvm.org/D140001.
>
> > This seems surprising/possibly wrong to me - do we have precedent from
> other flags to draw from?
>
> I feel it makes sense since `-fmodule-output=` will provide more information than `-fmodule-output`.
> So it is naturally to me that `-fmodule-output=`  has higher priority.
>
> For examples, I don't enumerate all the flags but I find the following cases in minutes:
> - `-fpack-struct=` has higher priority than `-fpack-struct`.
> - `-fsave-optimization-record=` has higher priority than  `-fsave-optimization-record=`.
> - `-ftime-report=` has higher priority than `-ftime-report`.
> - `-ftime-trace=` has higher priority than `-ftime-trace`.
>
> So I think the bahavior should be correct.

Fair enough - thanks for the references!
Nathan - is that consistent with your preference/understanding/experience?

>
> Thanks,
> Chuanqi
>
>
> ------------------------------------------------------------------
> From:David Blaikie <dblaikie@gmail.com>
> Send Time:2022年12月13日(星期二) 23:56
> To:chuanqi.xcq <yedeng.yd@linux.alibaba.com>
> Cc:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>; Nathan Sidwell <nathanmsidwell@gmail.com>; Jonathan Wakely <jwakely.gcc@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>
> Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
>
> I think Nathan might've been asking not only about what currently
> happens, but what we think should happen?
>
> On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
> >
> > Hi Nathan,
> >
> > > 1) Are these flags silently ignored, if no module output is to be generated? Or  is some kind of diagnostic generated?
> >
> > Currently, clang will generate the unused-command-line-argument warning for this case:
> >
> > ```
> > argument unused during compilation: '-fmodule-output' [-Wunused-command-line-argument]
> > ```
>
> Is that consistent with `-o`? (I assume so, but don't know - I guess
> there aren't many cases where `-o` is unused (maybe `-fsyntax-only`),
> so that behavior might be a bit less well specified)
>
> > > 2) what happens if you specify both -- do you get two outputs, a diagnostic, or
> > is one silently selected?
> >
> > If someone specify both `-fmodule-output` and `-fmodule-output=/path`,
> > the `-fmodule-output=/path` will be selected always no matter what the order is.
>
> This seems surprising/possibly wrong to me - do we have precedent from
> other flags to draw from?
>
> > And if multiple `-fmodule-output=/path` are specified, the last one will be selected.
> >
> > > 3) What is the behaviour if compilation fails?  Does nothing happen to the file
> > indicated (potentially leaving an older version there), or does the equivalent
> > of 'rm -f $MODULE.pcm' happen?
> >
> > The module file will be deleted. The behavior is the same with `-o`.
> >
> > Thanks,
> > Chuanqi
> >
> >
> > ------------------------------------------------------------------
> > From:Nathan Sidwell <nathan@acm.org>
> > Send Time:2022年12月12日(星期一) 22:30
> > To:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>
> > Cc:Nathan Sidwell <nathanmsidwell@gmail.com>; Jonathan Wakely <jwakely.gcc@gmail.com>; David Blaikie <dblaikie@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>
> > Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
> >
> > On 12/9/22 12:33, Iain Sandoe wrote:
> > > Hello all.
> > >
> > >> On 9 Dec 2022, at 01:58, chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
> > >>
> > >> It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here
> > >
> > > So FAOD (after this discussion) Chuanqi's current patchset implements the following in clang:
> > >
> > > -fmodule-output
> > >
> > >    - this causes the BMI to be saved in the CWG with the basename of the source file and a suffix of .pcm.
> > >
> > > -fmodule-output=<path>
> > >
> > >   - this causes the BMI to be saved at the path specified.
> > >
> >
> > 1) Are these flags silently ignored, if no module output is to be generated? Or
> > is some kind of diagnostic generated?
> >
> > 2) what happens if you specify both -- do you get two outputs, a diagnostic, or
> > is one silently selected?
> >
> > 3) What is the behaviour if compilation fails?  Does nothing happen to the file
> > indicated (potentially leaving an older version there), or does the equivalent
> > of 'rm -f $MODULE.pcm' happen?
> >
> > nathan
> >
> > --
> > Nathan Sidwell
> >
> >
>
>

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

[Nathan Sidwell]

I'm missing something from this discussion.  IIUC the claim is that these 2 new 
options -fmodule-output{,=NAME} are for build systems that want to specify the 
module output file.

But how do they specify the mapping from module/header-unit name to CMI, so that 
imports work?

Is this really a clang-specific mechanism, as it has no module mapper ATM (IIUC)?

nathan
-- 
Nathan Sidwell

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

[chuanqi.xcq]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

Hi Nathan,
> But how do they specify the mapping from module/header-unit name to CMI, so that 
> imports work?
>
> Is this really a clang-specific mechanism, as it has no module mapper ATM (IIUC)?
Yes, clang doesn't have a module mapper. And I remember Iain said he want to introduce these options in GCC.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Nathan Sidwell <nathan@acm.org>
Send Time:2022年12月15日(星期四) 06:29
To:David Blaikie <dblaikie@gmail.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>
Cc:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>; Nathan Sidwell <nathanmsidwell@gmail.com>; Jonathan Wakely <jwakely.gcc@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>
Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
I'm missing something from this discussion. IIUC the claim is that these 2 new 
options -fmodule-output{,=NAME} are for build systems that want to specify the 
module output file.
But how do they specify the mapping from module/header-unit name to CMI, so that 
imports work?
Is this really a clang-specific mechanism, as it has no module mapper ATM (IIUC)?
nathan
-- 
Nathan Sidwell

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

[Iain Sandoe]

> On 15 Dec 2022, at 05:58, chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:
> 
> Hi Nathan,
> 
> > But how do they specify the mapping from module/header-unit name to CMI, so that 
> > imports work?
> >
> > Is this really a clang-specific mechanism, as it has no module mapper ATM (IIUC)?
> 
> Yes, clang doesn't have a module mapper. And I remember Iain said he want to introduce these options in GCC.

To clarify:

 * 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.

thanks,
Iain


> 
> Thanks,
> 
> Chuanqi
> 
> ------------------------------------------------------------------
> From:Nathan Sidwell <nathan@acm.org>
> Send Time:2022年12月15日(星期四) 06:29
> To:David Blaikie <dblaikie@gmail.com>; chuanqi.xcq <yedeng.yd@linux.alibaba.com>
> Cc:Iain Sandoe <iain@sandoe.co.uk>; GCC Development <gcc@gcc.gnu.org>; Nathan Sidwell <nathanmsidwell@gmail.com>; Jonathan Wakely <jwakely.gcc@gmail.com>; ben.boeckel <ben.boeckel@kitware.com>
> Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files
> 
> I'm missing something from this discussion.  IIUC the claim is that these 2 new 
> options -fmodule-output{,=NAME} are for build systems that want to specify the 
> module output file.
> 
> But how do they specify the mapping from module/header-unit name to CMI, so that 
> imports work?
> 
> Is this really a clang-specific mechanism, as it has no module mapper ATM (IIUC)?
> 
> nathan
> -- 
> Nathan Sidwell
> 

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

[ben.boeckel]

On Thu, Dec 15, 2022 at 07:37:35 +0000, 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