dblaikie added a comment. In D134267#3844605 <https://reviews.llvm.org/D134267#3844605>, @ChuanqiXu wrote:
> In D134267#3815453 <https://reviews.llvm.org/D134267#3815453>, @dblaikie > wrote: > >>> This also tries to fix the problem I raised a year ago: >>> https://discourse.llvm.org/t/make-command-line-support-for-c-20-module-uniform-with-gcc/59144 >> >> I think this thread is fairly different from what this patch is proposing. >> >> @rsmith for discussion of adding effectively implicit modules support for >> C++20 modules - this seems like a pretty significant design choice, but >> something we (you and I, SG15, etc) have discussed before in terms of "how >> do we support 'Hello, World.'" situations without requiring something that >> amounts to a build system even for the simplest C++20 modules programs. >> Maybe this is it? But it surprises me a bit, and I don't think the linked >> thread is sufficiently relevant to draw conclusions about this direction. > > I don't understand your point a lot. From my point, the intention of the > thread > (https://discourse.llvm.org/t/make-command-line-support-for-c-20-module-uniform-with-gcc/59144) > are asking why the command line interfaces of clang are clearly more complex > than gcc. And @rsmith replies that: > >> Currently, Clang lacks two important features here: >> >> 1. Produce a .pcm file and a .o file from a single compilation action. > > in > https://discourse.llvm.org/t/make-command-line-support-for-c-20-module-uniform-with-gcc/59144/12. > And I think this is what this patch tries to do: (generate .pcm file and .o > file in one single compilation action). > > In fact, this doesn't change the behavior a lot. Previously, when we tried to > compile a `*.cppm` directly to `*.o`, the compiler will generate `*.pcm` > automatically too! Although the `*.pcm` file is only generated in `/tmp/` > files by default. And what this patch did is only to change the default > location for `*.pcm` files from `/tmp` to `module cache path`. And it > wouldn't affect the original 2 phase compilation model. > > BTW, this can simplify the use of modules significantly, see > https://reviews.llvm.org/D135507#change-gpsoCkM1g61J for example. The use of a module cache path I think is a pretty major difference between what was discussed on the discourse thread and what's being proposed here - a module "cache" is what starts to touch near Clang's old implicit modules that has real problems in terms of parallelism, etc. (granted what you're proposing here doesn't go all the way towards that - it doesn't have implicit actions to generate the pcm, at least) Is this what GCC Supports? I'd expect something more like Split DWARF, where the .pcm (or .dwo file) is placed next to the .o file - not in some separate directory (what sort of naming scheme would be used to ensure that paths in that directory are unique?). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134267/new/ https://reviews.llvm.org/D134267 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
