[PATCH] D137058: [Driver] [Modules] Support -fsave-std-c++-module-file (1/2)

[Ben Boeckel via Phabricator via cfe-commits]

ben.boeckel added a comment.

In D137058#3896999 <https://reviews.llvm.org/D137058#3896999>, @dblaikie wrote:

> Could you expound a bit on why "write the .pcm to the same path as the .o" isn't sufficient? (like Split DWARF does this, for instance - not sure we have lots of other things to extrapolate from (admittedly there is a flag for specifying the filename for Split DWARF too, but it's not a terribly official thing (doesn't have a '-f', '-g', etc prefix))

CMake doesn't support split dwarf (officially; it works, but CMake is just ignorant of it), so adapting to existing behavior would be more important there. For modules, however, explicit control is just much nicer to provide. It means that if heuristics change, CMake doesn't need patches to adapt to the logic. I would also vastly prefer that the `.pcm` filename match the *module* name, not the source file name. I'll also note that the example here is not suitable in the case of `Hello.cxx` and `Hello.cpp` existing at the same time (this is why CMake uses `Hello.cxx.o`). So some more control over the `.pcm` filename through more than source basename + `.pcm` is required in the general case (it is mostly mitigated if it is "replace `.o` with `.pcm`", but this is just unnecessary logic to ask anything interacting with Clang to deal with.

It also helps analyzers know that something else is happening explicitly and distributed builds to know what to bring back. Plus the other compilers offer controls over it; why does Clang have to be different?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137058