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

[David Blaikie via cfe-dev]

On Mon, Oct 25, 2021 at 7:04 PM chuanqi.xcq <yedeng.yd at linux.alibaba.com>
wrote:

> Hi Blaikie,
>
>
> >> 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.
> ---
> Understood. My point is that we could make clang support for C++20 more
> friendly by adding extra default behavior.
> And your point is that it may not be true in 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.
> ---
> I have a basic question about the Clang/LLVM policy. I remember that one
> of the policy of Clang/LLVM's command line system
> is to be compatible with GCC. This is basically true so that we could
> transfer the compiler used in various projects.
> Is this policy not true now?
>

I wouldn't state a general policy - though compatibility's certainly been a
motivating use case when Clang started out, and to some extent still is
today - but it's not always a case of "if GCC did it, Clang must accept
patches that match the functionality" - especially new functionality that's
in flux, I think there's some room for some nuance.

- Dave


>
> Thanks,
>
> Chuanqi
>
>
>
> ------------------------------------------------------------------
> From:David Blaikie <dblaikie at gmail.com>
> Send Time:2021年10月26日(星期二) 00:36
> To:chuanqi.xcq <yedeng.yd at linux.alibaba.com>; Nathan Sidwell <
> nathan at acm.org>; Richard Smith <richard at metafoo.co.uk>
> Cc:cfe-dev <cfe-dev at lists.llvm.org>
> Subject:Re: [cfe-dev] Make command line support for C++20 module uniform
> with GCC
>
> +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/417fc87a/attachment.html>