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

[chuanqi.xcq via cfe-dev]

Got it. So you think the better choice is to wait the decision from SG15 or authoritative conclusion from somebody, do I get your point?

From the perspective of a user, I like the GCC style more. After all, it is not easy to rememeber to add 'Xclang -emit-module-interface'
all the time. I would like to see if there is any comment to address the drawbacks in current command line support in GCC. 

Thanks,
Chuanqi


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

On Mon, Oct 25, 2021 at 7:04 PM chuanqi.xcq <yedeng.yd at linux.alibaba.com> 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?

I wouldn't state a general policy - though compatibility's certainly been a motivating use case when Clang started out, and to some extent still is today - but it's not always a case of "if GCC did it, Clang must accept patches that match the functionality" - especially new functionality that's in flux, I think there's some room for some nuance.

- Dave

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> 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
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/20211026/9d06cf70/attachment-0001.html>