[cfe-dev] Make command line support for C++20 module uniform with GCC
chuanqi.xcq via cfe-dev
cfe-dev at lists.llvm.org
Tue Oct 26 23:28:06 PDT 2021
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://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
--
Nathan Sidwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211027/63641f63/attachment-0001.html>
More information about the cfe-dev
mailing list