boris added a comment. 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. 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
