<div dir="ltr">On Wed, Jun 26, 2013 at 8:22 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><div>On Wed, Jun 26, 2013 at 5:03 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br>
> On Wed, Jun 26, 2013 at 7:53 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><br>
> wrote:<br>
>><br>
>> On Wed, Jun 26, 2013 at 3:56 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br>
>> > I'd like there to be a cl.exe compatible clang driver. I think the best<br>
>> > way<br>
>> > for this to work is to have the existing clang driver detect when it's<br>
>> > 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<br>
>> > (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<br>
>> > as<br>
>> > much as possible<br>
>> ><br>
>> > I think #2 is important so that cross-platform projects (like LLVM)<br>
>> > won't<br>
>> > have to spell clang options like -fcolor-diagnostics or<br>
>> > -Wc++11-extensions<br>
>> > twice.<br>
>><br>
>> Hmm, would cross-platform projects use the cl.exe-compatible driver?<br>
><br>
><br>
> Yes. Consider the use case of generating a Visual Studio project file that<br>
> uses clang for diagnostics and or codegen, and wanting to control those<br>
> diagnostics.<br>
<br>
</div></div>It seems like it should be possible to teach the build system to add<br>
the -Xwhatever in this case. Depending on how many conflicting options<br>
we have, cross-platform code may not be able to get away with using<br>
g++ driver options for the cl.exe driver anyway.<br></blockquote><div><br></div><div>What I have in mind right now is CMake, where every user pretty much does their own ad hoc flag checking and munging. Every CMake user would have to say add_cflag_if_supported("-fblah") / add_cflag_if_supported("-Xescape -fblah"), or it would be in some 'if clang' block.</div>
<div><br></div><div>One thing we could do to cut complexity here is forget about supporting the long tail of gcc driver options and just focus on a short-list of groups like -W, -f, -m, and maybe others.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe we should have some begin/end markers for g++ driver arguments<br>
so we don't have to add -Xwhatever before each one.</blockquote><div><br></div><div>I could see begin and end markers working, but I don't like the statefulness that they add to the flags. It's already hard to read ld's --start-group --end-group flags.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
>> > It's important to know that there are a few conflicts with MSVC like<br>
>> > -MD,<br>
>> > -MT, and things like -Zi where clang accepts -Z as a joined option, so<br>
>> > 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>
>> > /<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<br>
>> > 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<br>
>> > have to<br>
>> > be an escape flag. I propose -Xclang-driver, which is similar to<br>
>> > -Xclang,<br>
>> > except that it gets interpreted by the driver. Hopefully Microsoft<br>
>> > never<br>
>> > adds an -Xclang-driver flag. :)<br>
>><br>
>> 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.<br>
><br>
><br>
> Would you prefer -Xgcc-driver? I can see how -Xclang-driver would become<br>
> confusing, since they are both clang. Maybe -Xdriver? Honestly I don't<br>
> expect anyone will use the escape, but I wanted to propose it for<br>
> completeness and forwards compatibility if Microsoft adds a more severe<br>
> conflict for something core like -o.<br>
<br>
</div></div>They're both drivers, too, so -Xdriver doesn't seem quite right.<br>
Thoughts on -Xgcc for this case, and -Xcl.exe for the opposite case? I<br>
have reservations about this, since -Xfoo is currently used to mean<br>
"use these options when running the foo subprocess", but equally we<br>
can interpret it as meaning "here's an option in foo's option syntax".</blockquote><div><br></div><div>-Xgcc doesn't seem right since we invoke do invoke gcc to do things like assemble for mingw. How about something terribly explicit like --escaped-clang-args="multiple args here"?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
>> > Going forwards, Microsoft will probably add more flags to cl.exe. If<br>
>> > they<br>
>> > do and they conflict, we should value drop in compatibility above<br>
>> > backwards<br>
>> > compatibility and interpret the option as MSVC does, requiring users to<br>
>> > 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<br>
>> > 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>
><br>
><br>
><br>
</div>> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
</blockquote></div><br></div></div>