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

Tue Oct 11 08:44:35 PDT 2022

dblaikie added a comment.

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

> (trying not derail this discussion further)
>
> - Yes, the alternate solution proposed for the "Hello World" case would work with the module mapper interface.  However, the initial discussion was simply about being able to produce both the .PCM and .O artefacts from one invocation of the FE.

*nod* If there's some other patch that does just that - produces a .o/.pcm together in a single invocation, maybe that's a less contentious/easier patch to review/discuss/approve/commit. The number of process invocations involved in that (whether the driver, under the hood, invokes clang once to generate a .pcm and another to generate the .o) I'm less fussed about - I think that's something that can be improved separately - especially once/if someone wants to change the .pcm format to be lighter weight (not enough to generate the .o from, but enough for compilations /using/ the module to do so) - that'll drive a need for a monolithic .cppm -> {.o,.pcm} action.

> - It seemed reasonable to mention (since it's not vapourware, there are draft patches), but clearly some technical issues to address.

For sure.

> - I do not think this patch fully addresses the issue of harmonising GCC and clang's command lines for modular builds (because it does not deal with discovery of modular code in 'normally named' sources), and my investigation of trying to do this in the driver suggests that it would be much more complex than doing it in the FE.

Yes, that would be hard to implement in the driver - but my personal taste is that if the compiler's going to treat the input differently, or produce different outputs, it should be observable on the command line - either through different flags (`-x`) or a different file extension. I think that's been historically true? Though I realize it also comes up against "but we have all this C++ with these existing file extensions" and especially if GCC doesn't agree on that philosophy, Clang's going to have a hard time making a stand there... :/

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

https://reviews.llvm.org/D134267