[cfe-dev] Make command line support for C++20 module uniform with GCC
Andrew Tomazos via cfe-dev
cfe-dev at lists.llvm.org
Thu Oct 28 04:00:29 PDT 2021
On Wed, Oct 27, 2021 at 9:00 PM David Blaikie via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> 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.
>
Anyone know if Google has published any open source projects that use
modules yet? Or even any open source project that uses modules? I'm not
aware of any yet.
>
>> --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
>>
>> _______________________________________________
> 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/20211028/72354c11/attachment-0001.html>
More information about the cfe-dev
mailing list