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

via cfe-dev cfe-dev at lists.llvm.org
Wed Oct 27 06:50:32 PDT 2021


Let me just throw out there that any interface involved `-Xclang` is not a proper user-facing interface.  The -Xclang options aren’t intended for use by end users.
--paulr

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of chuanqi.xcq via cfe-dev
Sent: Wednesday, October 27, 2021 2:28 AM
To: Richard Smith <richard at metafoo.co.uk>; David Blaikie <dblaikie at gmail.com>; Nathan Sidwell <nathanmsidwell at gmail.com>
Cc: cfe-dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Make command line support for C++20 module uniform with GCC

I got it. The key point here is that since clang's module is already used in scale. So we couldn't change it arbitrarily before we get a clear solution.

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

On 10/25/21 22:04, chuanqi.xcq via cfe-dev 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?

GCC had the advantage of seeing clang's experiments.  The history is
different for the two compilers here -- clang developed 'implicit
modules', driven by a large build system.  with GCC I was very mindful
that 'hello world' should be simple to drive -- as you have found.
Clang has the tricky job of not breaking its existing interface.

As David says, what the best way to drive module compilations is no yet
clear.

nathan

>
> 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 <mailto: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 <mailto:cfe-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev__;!!JmoZiZGBv3RvKRSx!uljSy7xXR8IA-mBJrdxW-dpf-pOxmqiFrjUb1s50CZEGX-U311wC0tWXT2-YetWnMQ$>
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev><https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev*3E__;JQ!!JmoZiZGBv3RvKRSx!uljSy7xXR8IA-mBJrdxW-dpf-pOxmqiFrjUb1s50CZEGX-U311wC0tWXT283UKuIOw$>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev__;!!JmoZiZGBv3RvKRSx!uljSy7xXR8IA-mBJrdxW-dpf-pOxmqiFrjUb1s50CZEGX-U311wC0tWXT2-YetWnMQ$>
>


--
Nathan Sidwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211027/8200d398/attachment-0001.html>


More information about the cfe-dev mailing list