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!
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
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.
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).
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.
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.
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.
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.
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.
