See the discussion in https://lists.llvm.org/pipermail/cfe-dev/2021-October/069205.html for details. Simply, for the hello world example: ```C++ // say_hello.cpp module; #include <iostream> #include <string_view> export module Hello; export void SayHello (std::string_view const &name) { std::cout << "Hello " << name << "!\n"; } // main.cpp #include <string_view> import Hello; int main() { SayHello("world"); return 0; } ``` We could compile the example in GCC as: ``` g++ -std=c++20 -fmodules-ts say_hello.cpp main.cpp ``` And in Clang, we need: clang++ -std=c++20 say_hello.cppm --precompile -o Hello.pcm clang++ -std=c++20 -fprebuilt-module-path=. say_hello.pcm main.cpp It requires another line and two additional options `precompile` and `fprebuilt-module-path`. It would be more friendly to the users. Note that we didn't ask for use the new strategy to replace the old one. We want to keep the two strategies until we get clear solution that how module should interact with build systems.
In my experimental modules branch, I have implemented a similar scheme to that used by GCC. The interesting part about this is that for it to be convenient (and to avoid pre-parsing the source) we do not know that the source is a modular one at the start. so ... (assuming that the compilation is a c++20+ one) - set up a an ast consumer for the (potential) CMI output - sub-classed PCH write to make a deferred PCH writer - when a module is encountered, we need a mechanism for determining its on-disk name, for this I used Nathan Sidwell's libCody to implement the client-server interface to make a module-mapper. (there needs to be some mechanism to do this - or the advantage of lazy discovery is lost). - write out the module . potentially we also suppress the binary output -fmodule-only. ... I'll be offering that implementation for upstreaming.