[cfe-dev] Make command line support for C++20 module uniform with GCC
David Blaikie via cfe-dev
cfe-dev at lists.llvm.org
Thu Oct 28 12:36:47 PDT 2021
On Thu, Oct 28, 2021 at 4:00 AM Andrew Tomazos <andrewtomazos at gmail.com>
wrote:
> 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.
>
Google isn't using C++20 modules, only Clang Header Modules, where the
source is a subset valid non-modular code - so Google has published lots of
open source code that is compiled internally with Clang Header Modules -
but it's unobservable, basically, because it's also just valid non-modular
C++.
- Dave
>
>
>>
>>> --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/e0c184c1/attachment-0001.html>
More information about the cfe-dev
mailing list