[PATCH] D134267: [C++] [Modules] Support one phase compilation model for named modules

Wed Oct 19 20:04:15 PDT 2022

ChuanqiXu added a comment.

Yeah, I am a little bit surprising/confusing to see why we're talking about the **behavior** of `-fmodule-file`. I guess the intention of @iains is to throw the option to prove `-fc++-module-file-path` (or `-fc++-module-file-output`) is the better. The point here is about the `name` instead of the `behavior`.

In D134267#3869692 <https://reviews.llvm.org/D134267#3869692>, @iains wrote:

> In D134267#3869678 <https://reviews.llvm.org/D134267#3869678>, @dblaikie wrote:
>
>> (I'd still sort of lean towards "make it the same as the .o, but with the .pcm suffix" and if the build system wants to put things in other places, it can move them around - but I understand why that's not something everyone's on board with)
>
> Actually, I would think that to be a great default (and put it in the CWD just like the object),
> .. but it seems (in addition to the default) we do need a way to place specific module files - and I could imagine needing to make different places for different command line option sets.  Asking the driver or build system to move the file seems like spawning more processes and we'd still need a user-visible way to say where we wanted the file to be put.

For the default place, my original intention is to do not pollute (I know this may not be the best word) the user space. For example, when we compile a hello example (without modules):

  clang++ hello.cpp -o hello

we won't see `hello.o` in the current directory. It lives in the `/tmp` directory. I guess the intuition is to avoid users see things that they can ignore. So I chose to set the default place to be the same with the clang modules (under `~/cache/clang/module...`).

And for the needs to making different plans for different command line option sets, I feel like the current design (`-fc++-modules-cache-path` and `-fc++-module-bmi-output` (or `-fc++-module-file-output`)) is capable to handle it. For example, the different command line can set different `-fc++-modules-cache-path` or different `-fc++-module-file-output`.

>> Yeah, if the `-fmodule-file` syntax is currently only for input I don't think we need to try to overload it for output as well.
>
> My understanding [which could be flawed] is that the second syntax (which already exists, it's not an invention of this discussion) is intended to allow specification of output files.

No. (If I don't misunderstand your point), the `-fmodule-file` is only about the inputs. The difference between `-fmodule-file=a.pcm` and `-fmodule-file=A=a.pcm` is about the **lazy** module loading. For the first syntax, the clang will try to load `a.pcm` at the start. But for the second one, the clang will only try to load `a.pcm` when the module `A` is required. And I can't see the relationship with the output files.

>> Perhaps we could extend the --precompile flag to take a filename? (but then that'd potentially confuse things when you want to produce both PCM and .o, passing `--precompile` currently only produces the .pcm on the main output path... ).
>
> yeah, --precompile is well-defined to produce only the module (and I have a patch to alias it to -fmodule-only to match the GCC equivalent), it would not help to conflate that with the current objective.

Agreed. It may be not good to change the semantics of an existing option.

>> Anyone got a list of other compiler flags that take output file names? (I guess profile generation, maybe some other flags do this? Might be worth comparing/contrasting/seeking inspiration from those? I guess `-save-temps` uses the "same path, different suffix" strategy)
>
> I'll see if I can find my master list of modules options (tomorrow .. erm later today).

I guess @dblaikie is talking about the general output flags (not limited to modules). I'll try to make a list today too.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134267/new/

https://reviews.llvm.org/D134267