[cfe-dev] Make command line support for C++20 module uniform with GCC

David Blaikie via cfe-dev cfe-dev at lists.llvm.org
Mon Oct 25 09:26:30 PDT 2021


+Nathan and Richard as folks with some context here.

On Mon, Oct 25, 2021 at 1:57 AM chuanqi.xcq via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi all,
>
>    Recently I am playing with C++20 modules and I found that the command
> line support of GCC
> is much better than Clang. Here is an 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;
> }
> ```
>
> To compile the example, in gcc we need:
> ```
> g++ -std=c++20 -fmodules-ts say_hello.cpp main.cpp
> ```
>
> And in clang, we need:
> ```
>
> clang++ -std=c++20 -fmodules-ts -Xclang -emit-module-interface -c
> say_hello.cpp -o Hello.pcm
>
> clang++ -std=c++20 -fmodules-ts -fprebuilt-module-path=. main.cpp
> say_hello.cpp
> ```
>
> Yeah, in clang we need to another line to emit module interface explicitly
> and another option
> to tell the prebuilt-module-path. And in GCC, this happens by default,
> when GCC find it is compiling
> a c++20 module, it would generate the module interface automatically to
> the path:
> ```
> gcm.cache/filename.gcm
> ```
> It would create `gcm.cache` in case it doesn't exist.
>
> And GCC would search prebuilt module interface in `gcm.cache`
> automatically.
>
> It looks much more friendly to me. The intention of this mail is to ask if
> you think it is the right direction
> to make the clang's command line support for c++20 module more like GCC.
> The different I see now includes:
> - Generate prebuilt module interface automatically. (And generate it to a
> specific directory automatically)
> - Have a default value for prebuilt module path.
>

This sort of interaction is probably not going to be how modules are
generally built/supported as far as I understand it - it's opaque to the
build system, so may make it more difficult for the build system to know
when things need to be rebuilt, and also wouldn't support any kind of
distributed build system.

The specifics of how GCC, Clang, (& maybe other compilers) and various
build systems may end up interacting on the command line and filesystem
(module discovery outside the current build for system-installed library
dependencies) is still being discussed and debated in places like C++'s
SG15 tooling working group.

That doesn't mean we can't experiment further with things like this, but
I'm not sure we will/should be supporting cross-compiler interface
compatibility until we are a bit more sure about what the best thing to
standardize no is.


> I am wondering if any one more familiar with the clang's command line and
> file system would love to
> support this (I am not so familiar with it). Although It may take more
> time, I would love to support if others are busy.
>
> Thanks,
> Chuanqi
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211025/089d7519/attachment-0001.html>


More information about the cfe-dev mailing list