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

Fri Oct 28 11:32:38 PDT 2022

ben.boeckel added a comment.

In D134267#3876071 <https://reviews.llvm.org/D134267#3876071>, @dblaikie wrote:

> I'm getting a bit exhausted with all the words involved here & not sure how to simplify/clarify this.
>
> If @ben.boeckel has particular use cases, it might be easier for him to be here discussing them so we can discuss the tradeoffs directly rather than through intermediaries.

Sorry, I've been lax on actually keeping up-to-date on all of these Clang threads.

The current state is that CMake's test suite for C++ modules does not work with clang because it doesn't provide the control CMake needs to do its explicit builds. @ChuanqiXu's MyP1689 branch is close except that the `.pcm` output path can't seem to be controlled closely enough for reliable builds. Namely, I would like:

- the ability to disable the module cache (completely); CMake doesn't need nor want it
- the ability to say put the generated `.pcm` that this TU will generate goes *here*

The latter is currently a juggle of flags and restrictions that I haven't been able to figure out. Without something like `-fmodule-output-path=`, convincing Clang to output its `.pcm` file to where CMake wants it to be is some combination of `-fmodules-cache-path=` and `-fmodule-name=` while hoping that the internal path computation inside of Clang makes what CMake wants. It's just far easier to have something like `-o` that gives the answer straight away.

For the former, I use `-x c++module` as well so that I don't have to care about any extension-sniffing behaviors. I also need to give a bogus `-fmodule-cache-path=` for module consumers because as soon as `import` is seen, it wants to run off to look at the cache instead of noticing that there's a `-fmodule-file=` for everything it needs already and the cache is 100% unused.

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

https://reviews.llvm.org/D134267