<div dir="ltr">On Wed, Jun 26, 2013 at 7:53 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Jun 26, 2013 at 3:56 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>

</div><div class="im">> I'd like there to be a cl.exe compatible clang driver.  I think the best way<br>
> for this to work is to have the existing clang driver detect when it's being<br>
> invoked as cl.exe, similar to how clang++ vs. clang works today.  For<br>
> testing, there should be a -ccc-msvc option which turns on the same<br>
> behavior.<br>
><br>
> Some relevant past discussion on this topic:<br>
> <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html</a><br>
><br>
> The priorities for the driver should be, in order:<br>
><br>
> 1. Drop in compatibility with MSVC<br>
> 2. Compatibility with the existing clang driver<br>
> 3. Don't change the meaning of existing gcc-style driver command lines (an<br>
> argument with a / prefix is an input path, not an option)<br>
> 4. Avoid -cc1 option explosion by aliasing MSVC options to gcc options as<br>
> much as possible<br>
><br>
> I think #2 is important so that cross-platform projects (like LLVM) won't<br>
> have to spell clang options like -fcolor-diagnostics or -Wc++11-extensions<br>
> twice.<br>
<br>
</div>Hmm, would cross-platform projects use the cl.exe-compatible driver?</blockquote><div><br></div><div>Yes.  Consider the use case of generating a Visual Studio project file that uses clang for diagnostics and or codegen, and wanting to control those diagnostics.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> It's important to know that there are a few conflicts with MSVC like -MD,<br>
> -MT, and things like -Zi where clang accepts -Z as a joined option, so there<br>
> needs to be a good solution for disambiguating them.<br>
><br>
> Previously people have discussed using the slash prefix to disambiguate<br>
> between the MSVC and clang meanings, but since cl.exe accepts both - and /<br>
> prefixes for all of its options, I don't like this approach.  There are<br>
> probably many Unix expats out there on Windows consistently using dash-style<br>
> option prefixes everywhere, like me.<br>
><br>
> I think clang should give a higher precedence to all MSVC options before<br>
> falling back to gcc style options.  To resolve conflicts, there will have to<br>
> be an escape flag.  I propose -Xclang-driver, which is similar to -Xclang,<br>
> except that it gets interpreted by the driver.  Hopefully Microsoft never<br>
> adds an -Xclang-driver flag.  :)<br>
<br>
</div>It sounds like your mental model is that we have a "Clang driver", and<br>
a set of extensions for a "cl.exe-compatible driver". I think it might<br>
be a better perspective to think about this as a "g++-compatible<br>
driver" and a "cl.exe-compatible driver". I guess what I'm saying is<br>
that I don't like the name "-Xclang-driver" as a prefix for an option<br>
to the g++-compatible driver.</blockquote><div><br>Would you prefer -Xgcc-driver?  I can see how -Xclang-driver would become confusing, since they are both clang.  Maybe -Xdriver?  Honestly I don't expect anyone will use the escape, but I wanted to propose it for completeness and forwards compatibility if Microsoft adds a more severe conflict for something core like -o.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> Going forwards, Microsoft will probably add more flags to cl.exe.  If they<br>
> do and they conflict, we should value drop in compatibility above backwards<br>
> compatibility and interpret the option as MSVC does, requiring users to use<br>
> the escape if they need the conflicting option.<br>
><br>
> I've attached patches for LLVM and clang to start implementing this.<br>
> They're pretty rough, but I really want to get something committed and<br>
> iterate on it, even if I back up and completely rewrite with a separate<br>
> OptTable.  I've been testing the driver by renaming clang.exe to cl.exe and<br>
> putting it in the cwd before running MSBuild.  It currently fails due to<br>
> UTF-16 response files and -Fo takes an output directory which needs -cc1<br>
> logic.<br>
><br>
> Thoughts?<br>
</div></div></blockquote></div><br></div></div>