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

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D134267#3852047 <https://reviews.llvm.org/D134267#3852047>, @boris wrote:

> Just to add a few points on the module mapper discussion: overall, the current view is that there are two ways to handle C++20 modules from the build system's POV: (1) pre-scan the codebase to figure out what is what and who depends on whom ahead of compilation and (2) module mapper where the compiler and the build system discover this information interactively during compilation. Naturally, both approaches have advantages and disadvantages.
>
> The major issue with the pre-scan is that there needs to be a clear boundary where the codebase ends. This can be an acceptable requirement for monorepo-style projects but not for multirepo. Even for monorepo, there are often external dependencies (C/C++ standard library, maybe system libraries like OpenSSL) that require special considerations. There is also some concern for the performance of the pre-scan on larger codebases. On the other hand, pre-scan is likely to be easier to integrate with legacy and meta-build systems like CMake.
>
> The major issue with the module mapper is the need for deeper integration with the build system as well as the overall complexity of the client/server architecture. There is also some concern for the resource consumption since the mapper approach may need to spawn nested compiler invocations to build missing BMIs. The main advantage of the module mapper is probably the fact that the information comes from the source (the compiler) and if/when necessary, which sidesteps the whole issue of doing too little or too much pre-scanning (for example, due to imprecise boundaries, some discrepancies in the compiler options, etc).
>
> GCC implements the mapper approach (with the reusable parts factored into libcody) and we successfully use that in build2. We would definitely like to see the module mapper supported by Clang, ideally with the GCC's interface (so that we could use the existing mapper for both). In the build2's case specifically, pre-scan is not a viable option since it's a multirepo-first build system.
>
> Also, a comment on the earlier point made:
>
>> I do not believe that the client-sever build system model (a.k.a. P1184 <https://reviews.llvm.org/P1184> / module mapper) is quite the same thing as implicit modules
>
> Strongly agree. The key difference here is that with the mapper there is a single entity (the build system) that decides which things need to be (re)built and where rather than multiple compiler instances trying to come up with something consistent.

Hi Boris, thanks for the update. (Although I feel this must not be the right place to discuss the topic).

Personally, I don't have strong feeling about the client-server model (pursue it or object it). And I'd love to support the per-scan based method since it is relatively easy for compiler and build systems. So that other build systems (including but not limited to cmake) can support modules more quickly. Then the more users can try to start to use modules actually.  So that then we can get more backport to improve. And I feel like the two option may not be mutual exclusive with each other. For example, my experimental support for P1689 <https://reviews.llvm.org/P1689> is at: https://github.com/ChuanqiXu9/llvm-project/commit/fd809e8fcba497eb9458d7dbb6fc194044b19521. The implementation looks relatively trivial to me. The simplicity is pretty important. Then I won't feel it is too late to support the client-server model in clang if someday the client-server  model shows great advances.


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

https://reviews.llvm.org/D134267