VS2017: LLVM Compiler Toolchain Plugin

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
After not doing any C++dev for some time, I, today (yes, I'm slow), updated the "LLVM Compiler Toolchain" plugin for MSVC. And, I cannot say anything else then, "Just what the doctor ordered, perfect" This plugin makes Clang/LLVM a first-class-citizen. The support for lld-link is just the best, and using the -flto=thin option blows MSVC straight out of the water for many software projects (many more to thank there).

My Thanks (and Cheers) go out to Zach Turner for providing this linking pin in the process of getting Clang/LLVM working properly (and in a non-conflicting way in conjunction with MSVC) on the Windows platform from within the Visual Studio 2017 IDE. Thanks, mate, we owe you one!

degski
--
If something cannot go on forever, it will stop" - Herbert Stein

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
Nice!  Thanks for your early feedback too.  The one remaining thing which I’d like to add is the ability to print the input file name to stdout.  Currently when you build a large project you see no output and it looks like the build is hung, potentially for several minutes.  It would be nice to match what msvc does and generate build output 

On Fri, Sep 28, 2018 at 4:13 AM degski via cfe-dev <[hidden email]> wrote:
After not doing any C++dev for some time, I, today (yes, I'm slow), updated the "LLVM Compiler Toolchain" plugin for MSVC. And, I cannot say anything else then, "Just what the doctor ordered, perfect" This plugin makes Clang/LLVM a first-class-citizen. The support for lld-link is just the best, and using the -flto=thin option blows MSVC straight out of the water for many software projects (many more to thank there).

My Thanks (and Cheers) go out to Zach Turner for providing this linking pin in the process of getting Clang/LLVM working properly (and in a non-conflicting way in conjunction with MSVC) on the Windows platform from within the Visual Studio 2017 IDE. Thanks, mate, we owe you one!


degski
--
If something cannot go on forever, it will stop" - Herbert Stein
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
The suggestion here is to make than an off-by-default option in Clang-CL:

  https://bugs.llvm.org/show_bug.cgi?id=31957

I think it should be on by default (and not optional), but maybe you are
interested in it.

Thanks from me for the VS infrastructure. I wrote about it here:

 
https://blogs.msdn.microsoft.com/vcblog/2018/09/18/exploring-clang-tooling-part-0-building-your-code-with-clang/

and will have follow-up posts out soon made possible by it!

Thanks,

Stephen.

On 28/09/18 16:06, Zachary Turner via cfe-dev wrote:

> Nice!  Thanks for your early feedback too.  The one remaining thing
> which I’d like to add is the ability to print the input file name to
> stdout.  Currently when you build a large project you see no output and
> it looks like the build is hung, potentially for several minutes.  It
> would be nice to match what msvc does and generate build output
>
> On Fri, Sep 28, 2018 at 4:13 AM degski via cfe-dev
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     After not doing any C++dev for some time, I, today (yes, I'm slow),
>     updated the "LLVM Compiler Toolchain" plugin for MSVC. And, I cannot
>     say anything else then, "Just what the doctor ordered, perfect" This
>     plugin makes Clang/LLVM a first-class-citizen. The support for
>     lld-link is just the best, and using the -flto=thin option blows
>     MSVC straight out of the water for many software projects (many more
>     to thank there).
>
>     My Thanks (and Cheers) go out to *Zach Turner* for providing this
>     linking pin in the process of getting Clang/LLVM working properly
>     (and in a non-conflicting way in conjunction with MSVC) on the
>     Windows platform from within the Visual Studio 2017 IDE. Thanks,
>     mate, we owe you one!
>
>
>     degski
>     --
>     /*/*“*/If something cannot go on forever, it will stop" - Herbert
>     Stein*/
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
I hadn’t seen that blog post, thanks!

I don’t have a particularly strong opinion on the stdout option, but several other project members do. Can you elaborate on why you think it should be on by default (and separately, why it should not be possible to disable)? The thinking on our side is that this is a task better handled by the build system, and presently most build systems today just end up filtering this out anyway.

My current idea for how to implement this is to have clang detect the presence of a magical undocumented environment variable, and have the MSBuild integration just set this variable.


On Fri, Sep 28, 2018 at 11:33 AM Stephen Kelly via cfe-dev <[hidden email]> wrote:
The suggestion here is to make than an off-by-default option in Clang-CL:

  https://bugs.llvm.org/show_bug.cgi?id=31957

I think it should be on by default (and not optional), but maybe you are
interested in it.

Thanks from me for the VS infrastructure. I wrote about it here:


https://blogs.msdn.microsoft.com/vcblog/2018/09/18/exploring-clang-tooling-part-0-building-your-code-with-clang/

and will have follow-up posts out soon made possible by it!

Thanks,

Stephen.

On 28/09/18 16:06, Zachary Turner via cfe-dev wrote:
> Nice!  Thanks for your early feedback too.  The one remaining thing
> which I’d like to add is the ability to print the input file name to
> stdout.  Currently when you build a large project you see no output and
> it looks like the build is hung, potentially for several minutes.  It
> would be nice to match what msvc does and generate build output
>
> On Fri, Sep 28, 2018 at 4:13 AM degski via cfe-dev
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     After not doing any C++dev for some time, I, today (yes, I'm slow),
>     updated the "LLVM Compiler Toolchain" plugin for MSVC. And, I cannot
>     say anything else then, "Just what the doctor ordered, perfect" This
>     plugin makes Clang/LLVM a first-class-citizen. The support for
>     lld-link is just the best, and using the -flto=thin option blows
>     MSVC straight out of the water for many software projects (many more
>     to thank there).
>
>     My Thanks (and Cheers) go out to *Zach Turner* for providing this
>     linking pin in the process of getting Clang/LLVM working properly
>     (and in a non-conflicting way in conjunction with MSVC) on the
>     Windows platform from within the Visual Studio 2017 IDE. Thanks,
>     mate, we owe you one!
>
>
>     degski
>     --
>     /*/*“*/If something cannot go on forever, it will stop" - Herbert
>     Stein*/
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
In reply to this post by Yvan Roux via cfe-dev
On Fri, 28 Sep 2018 at 18:06, Zachary Turner <[hidden email]> wrote:
Nice!  Thanks for your early feedback too.  The one remaining thing which I’d like to add is the ability to print the input file name to stdout.  Currently when you build a large project you see no output and it looks like the build is hung, potentially for several minutes.  It would be nice to match what msvc does and generate build output

Ironically, I use that "feature" to distinguish a Clang build from a MSVC build (by looking at the output). Iff your going out of your way to generate the same output as MSVC, it might be interesting to see whether it's possible to output f.e. "clang version 8.0.0 (trunk)", as the first line of the output (maybe a clang-cl command line option, a la "-v", might be easier and would make that optional).

Have a nice day,

degski

--
If something cannot go on forever, it will stop" - Herbert Stein

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
In reply to this post by Yvan Roux via cfe-dev
On 28/09/18 23:30, Zachary Turner via cfe-dev wrote:
> I hadn’t seen that blog post, thanks!
>
> I don’t have a particularly strong opinion on the stdout option, but
> several other project members do. Can you elaborate on why you think it
> should be on by default

Consistency with MSVC.

I'll quote you on this:

 > stdout.  Currently when you build a large project you see no output and
 > it looks like the build is hung, potentially for several minutes.  It
 > would be nice to match what msvc does and generate build output

That's the exact experience I had.

> (and separately, why it should not be possible
> to disable)?

Self consistency. This is less important I think.

> The thinking on our side is that this is a task better
> handled by the build system

There are many more buildsystems than Clang-CLs.

> , and presently most build systems today just
> end up filtering this out anyway.

I'm not aware of that.

> My current idea for how to implement this is to have clang detect the
> presence of a magical undocumented environment variable, and have the
> MSBuild integration just set this variable.

I don't understand the reasoning behind deliberately diverging from what
MSVC does in a tool which emulates it.

I can keep my patch around if I need to anyway. I just thought I'd point
to to the bug report so you could see the existing discussion.

Thanks,

Stephen.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
To be clear, there’s no disagreement that when using MSBuild you should have exactly the same experience with clang-cl and cl. And by exact same experience, that means if anything is going on behind the scenes to make sure the filename is printed, it should be invisible to the user.

The question is about what to do when not using MSBuild. Someone on Linux who is running clang-cl from the command line would be disturbed by the output because it’s not standard behavior for tools on Linux to do that.

With the implementation strategy I proposed in the earlier message, it seems like we can have the best of both worlds. There’s only really one tool I’m aware of that requires this output (MSBuild), and all other use cases seem to prefer not having it.
On Sat, Sep 29, 2018 at 1:23 AM Stephen Kelly via cfe-dev <[hidden email]> wrote:
On 28/09/18 23:30, Zachary Turner via cfe-dev wrote:
> I hadn’t seen that blog post, thanks!
>
> I don’t have a particularly strong opinion on the stdout option, but
> several other project members do. Can you elaborate on why you think it
> should be on by default

Consistency with MSVC.

I'll quote you on this:

 > stdout.  Currently when you build a large project you see no output and
 > it looks like the build is hung, potentially for several minutes.  It
 > would be nice to match what msvc does and generate build output

That's the exact experience I had.

> (and separately, why it should not be possible
> to disable)?

Self consistency. This is less important I think.

> The thinking on our side is that this is a task better
> handled by the build system

There are many more buildsystems than Clang-CLs.

> , and presently most build systems today just
> end up filtering this out anyway.

I'm not aware of that.

> My current idea for how to implement this is to have clang detect the
> presence of a magical undocumented environment variable, and have the
> MSBuild integration just set this variable.

I don't understand the reasoning behind deliberately diverging from what
MSVC does in a tool which emulates it.

I can keep my patch around if I need to anyway. I just thought I'd point
to to the bug report so you could see the existing discussion.

Thanks,

Stephen.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
On 29/09/18 15:54, Zachary Turner via cfe-dev wrote:
> To be clear, there’s no disagreement that when using MSBuild you should
> have exactly the same experience with clang-cl and cl. And by exact same
> experience, that means if anything is going on behind the scenes to make
> sure the filename is printed, it should be invisible to the user.

Hmm, I don't know what MSBuild has to do with it. Why shouldn't the
experience be the same with Ninja, or another buildsystem, or just when
running both from the command line? Maybe this is where I'm missing
something.

> The question is about what to do when not using MSBuild. Someone on
> Linux who is running clang-cl from the command line would be disturbed
> by the output because it’s not standard behavior for tools on Linux to
> do that.

Does CL.exe on linux with wine print the name? Why should Clang-CL be
different?

> With the implementation strategy I proposed in the earlier message, it
> seems like we can have the best of both worlds. There’s only really one
> tool I’m aware of that requires this output (MSBuild), and all other use
> cases seem to prefer not having it.
What do you mean 'best of both worlds'?

Does MSBuild "require" this output? Is this where I'm missing something
here?

Anyway, I don't follow your logic and I don't understand desire to not
behave like CL.exe in this sense (given the many other senses that
Clang-CL does behave like CL.exe). But, I can live with not following
that logic and without understanding the desire to make Clang-CL
different. I'll just assume I'm missing something.

Thanks,

Stephen.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
On Sat, Sep 29, 2018 at 8:06 PM, Stephen Kelly via cfe-dev
<[hidden email]> wrote:

> On 29/09/18 15:54, Zachary Turner via cfe-dev wrote:
>>
>> To be clear, there’s no disagreement that when using MSBuild you should
>> have exactly the same experience with clang-cl and cl. And by exact same
>> experience, that means if anything is going on behind the scenes to make
>> sure the filename is printed, it should be invisible to the user.
>
>
> Hmm, I don't know what MSBuild has to do with it. Why shouldn't the
> experience be the same with Ninja, or another buildsystem, or just when
> running both from the command line? Maybe this is where I'm missing
> something.

It's not a goal of clang-cl to emulate MSVC perfectly. It's just
aiming to be compatible so that's it's easy for users to switch
between them. The goal is to be better than MSVC :-)

I think the behaviour of not echoing the filename is better and should
be the default, but I can see that it's useful when using a build
system that doesn't provide any separate indication of progress, so
let's add a /showFilenames flag as discussed on
https://bugs.llvm.org/show_bug.cgi?id=31957

I will try to get a patch out unless someone beats me to it.

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
It occurred to me there is one case where I think showing filenames is not only helpful, but necessary.  It is the case where you specify multiple file names on a single command line invocation.

Most build systems will not ever invoke this, but the compiler does, and without printing filenames to stdout it will be impossible for the user to know what's happening in this case.

On Mon, Oct 1, 2018 at 5:52 AM Hans Wennborg via cfe-dev <[hidden email]> wrote:
On Sat, Sep 29, 2018 at 8:06 PM, Stephen Kelly via cfe-dev
<[hidden email]> wrote:
> On 29/09/18 15:54, Zachary Turner via cfe-dev wrote:
>>
>> To be clear, there’s no disagreement that when using MSBuild you should
>> have exactly the same experience with clang-cl and cl. And by exact same
>> experience, that means if anything is going on behind the scenes to make
>> sure the filename is printed, it should be invisible to the user.
>
>
> Hmm, I don't know what MSBuild has to do with it. Why shouldn't the
> experience be the same with Ninja, or another buildsystem, or just when
> running both from the command line? Maybe this is where I'm missing
> something.

It's not a goal of clang-cl to emulate MSVC perfectly. It's just
aiming to be compatible so that's it's easy for users to switch
between them. The goal is to be better than MSVC :-)

I think the behaviour of not echoing the filename is better and should
be the default, but I can see that it's useful when using a build
system that doesn't provide any separate indication of progress, so
let's add a /showFilenames flag as discussed on
https://bugs.llvm.org/show_bug.cgi?id=31957

I will try to get a patch out unless someone beats me to it.

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
s/the compiler does/the compiller does support this/

On Mon, Oct 1, 2018 at 10:29 AM Zachary Turner <[hidden email]> wrote:
It occurred to me there is one case where I think showing filenames is not only helpful, but necessary.  It is the case where you specify multiple file names on a single command line invocation.

Most build systems will not ever invoke this, but the compiler does, and without printing filenames to stdout it will be impossible for the user to know what's happening in this case.

On Mon, Oct 1, 2018 at 5:52 AM Hans Wennborg via cfe-dev <[hidden email]> wrote:
On Sat, Sep 29, 2018 at 8:06 PM, Stephen Kelly via cfe-dev
<[hidden email]> wrote:
> On 29/09/18 15:54, Zachary Turner via cfe-dev wrote:
>>
>> To be clear, there’s no disagreement that when using MSBuild you should
>> have exactly the same experience with clang-cl and cl. And by exact same
>> experience, that means if anything is going on behind the scenes to make
>> sure the filename is printed, it should be invisible to the user.
>
>
> Hmm, I don't know what MSBuild has to do with it. Why shouldn't the
> experience be the same with Ninja, or another buildsystem, or just when
> running both from the command line? Maybe this is where I'm missing
> something.

It's not a goal of clang-cl to emulate MSVC perfectly. It's just
aiming to be compatible so that's it's easy for users to switch
between them. The goal is to be better than MSVC :-)

I think the behaviour of not echoing the filename is better and should
be the default, but I can see that it's useful when using a build
system that doesn't provide any separate indication of progress, so
let's add a /showFilenames flag as discussed on
https://bugs.llvm.org/show_bug.cgi?id=31957

I will try to get a patch out unless someone beats me to it.

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: VS2017: LLVM Compiler Toolchain Plugin

Yvan Roux via cfe-dev
I wouldn't say it's necessary, but I can certainly see that it's helpful.

Here's a patch: https://reviews.llvm.org/D52773

On Mon, Oct 1, 2018 at 7:30 PM, Zachary Turner <[hidden email]> wrote:

> s/the compiler does/the compiller does support this/
>
> On Mon, Oct 1, 2018 at 10:29 AM Zachary Turner <[hidden email]> wrote:
>>
>> It occurred to me there is one case where I think showing filenames is not
>> only helpful, but necessary.  It is the case where you specify multiple file
>> names on a single command line invocation.
>>
>> Most build systems will not ever invoke this, but the compiler does, and
>> without printing filenames to stdout it will be impossible for the user to
>> know what's happening in this case.
>>
>> On Mon, Oct 1, 2018 at 5:52 AM Hans Wennborg via cfe-dev
>> <[hidden email]> wrote:
>>>
>>> On Sat, Sep 29, 2018 at 8:06 PM, Stephen Kelly via cfe-dev
>>> <[hidden email]> wrote:
>>> > On 29/09/18 15:54, Zachary Turner via cfe-dev wrote:
>>> >>
>>> >> To be clear, there’s no disagreement that when using MSBuild you
>>> >> should
>>> >> have exactly the same experience with clang-cl and cl. And by exact
>>> >> same
>>> >> experience, that means if anything is going on behind the scenes to
>>> >> make
>>> >> sure the filename is printed, it should be invisible to the user.
>>> >
>>> >
>>> > Hmm, I don't know what MSBuild has to do with it. Why shouldn't the
>>> > experience be the same with Ninja, or another buildsystem, or just when
>>> > running both from the command line? Maybe this is where I'm missing
>>> > something.
>>>
>>> It's not a goal of clang-cl to emulate MSVC perfectly. It's just
>>> aiming to be compatible so that's it's easy for users to switch
>>> between them. The goal is to be better than MSVC :-)
>>>
>>> I think the behaviour of not echoing the filename is better and should
>>> be the default, but I can see that it's useful when using a build
>>> system that doesn't provide any separate indication of progress, so
>>> let's add a /showFilenames flag as discussed on
>>> https://bugs.llvm.org/show_bug.cgi?id=31957
>>>
>>> I will try to get a patch out unless someone beats me to it.
>>>
>>> Thanks,
>>> Hans
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev