public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "chuanqi.xcq" <yedeng.yd@linux.alibaba.com>
To: "David Blaikie" <dblaikie@gmail.com>,
	"gcc Mailing List" <gcc@gcc.gnu.org>,
	"Iain Sandoe" <iain@sandoe.co.uk>,
	"Nathan Sidwell" <nathanmsidwell@gmail.com>,
	"ben.boeckel" <ben.boeckel@kitware.com>
Subject: Re: Naming flag for specifying the output file name for Binary Module Interface files
Date: Wed, 07 Dec 2022 10:30:07 +0800	[thread overview]
Message-ID: <b38b64fd-4bb7-417a-bc29-ad7c3ca1665e.yedeng.yd@linux.alibaba.com> (raw)
In-Reply-To: <96699ff0-f4d7-4276-8af7-5a4ce9735174@acm.org>

[-- 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

  parent reply	other threads:[~2022-12-07  2:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-06 21:03 David Blaikie
2022-12-07  0:35 ` Nathan Sidwell
2022-12-07  1:45   ` Jonathan Wakely
2022-12-07  2:30   ` chuanqi.xcq [this message]
2022-12-07 15:23     ` Jonathan Wakely
2022-12-07 15:45       ` ben.boeckel
2022-12-07 16:18         ` Iain Sandoe
2022-12-07 16:29           ` ben.boeckel
2022-12-07 16:52           ` Nathan Sidwell
2022-12-07 16:58             ` Iain Sandoe
2022-12-07 17:00               ` Nathan Sidwell
2022-12-09  1:58                 ` chuanqi.xcq
2022-12-09 17:33                   ` Iain Sandoe
2022-12-09 17:43                     ` David Blaikie
2022-12-12 14:30                     ` Nathan Sidwell
2022-12-13  3:10                       ` chuanqi.xcq
2022-12-13 15:56                         ` David Blaikie
2022-12-14  9:56                           ` chuanqi.xcq
2022-12-14 18:39                             ` David Blaikie
2022-12-14 22:29                               ` Nathan Sidwell
2022-12-15  5:58                                 ` chuanqi.xcq
2022-12-15  7:37                                   ` Iain Sandoe
2022-12-15 13:21                                     ` ben.boeckel
2022-12-07 16:43       ` Nathan Sidwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b38b64fd-4bb7-417a-bc29-ad7c3ca1665e.yedeng.yd@linux.alibaba.com \
    --to=yedeng.yd@linux.alibaba.com \
    --cc=ben.boeckel@kitware.com \
    --cc=dblaikie@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=iain@sandoe.co.uk \
    --cc=nathanmsidwell@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).