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

David Blaikie via cfe-dev cfe-dev at lists.llvm.org
Wed Oct 27 13:59:48 PDT 2021


On Wed, Oct 27, 2021 at 6:50 AM <paul.robinson at sony.com> wrote:

> 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.
>

Yeah, it's certainly still in flux/unclear how this should look long-term.
I mean Google's been using these -Xclang interfaces for building explicit
Clang Modules for years at this point - so probably worth giving a
legitimate/official interface for that use case, even if it doesn't answer
all the questions about how C++20 modules will be consumed.


> --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.
>

I think there's probably space to experiment with more things without
breaking the interfaces currently in use - but equally not immediately
going for GCC compatibility for its own sake either.


>
>
> 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/9221617f/attachment-0001.html>


More information about the cfe-dev mailing list