<div dir="ltr">On Wed, Jun 26, 2013 at 10:12 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</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 dir="ltr">This thread's chain of emails is somewhat tricky to reply to so I'll just start fresh... Sorry for that...<div>
<br><div>I think we need to admit that there is some preferred Clang set of options and option syntaxes. They may be chosen to be consistent with GCC in some ways, but they're not actually compatible. The most frequently cited here is actually a case in point: GCC doesn't support -fcolor-diagnostics, so I don't think we can sensibly call it '-Xgcc-driver=-fcolor-diagnostics'.</div>

<div><br></div><div><br></div><div>But let's simplify this: we really don't need to support *all* of the existing command line syntax when operating in a cl.exe compatible mode. Instead, let's focus on what the important use cases are for user provided flags that might be useful to support across platforms:<br>

</div><div><br></div><div>- High level driver flags like '--coverage', '--target', .... I think these are OK as I don't think MS supports double-dash syntax, or if they do I doubt many use it.</div></div>
</div></blockquote><div><br></div><div>Yep, there are no double-dash flags, or at least I can't find them.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>- Warnings using the '-Wsome-long-name' syntax: are there any conflicts here?</div><div><br></div><div>- Language features using the '-fsome-long-name' syntax: are there any conflicts here?</div>

<div><br></div><div>- Machine features using the '-msome-long-name' syntax: are there any conflicts here?</div><div><br></div><div>- Debugging features using the '-gsome-long-name' syntax? Not sure we even want this, but maybe: are there any conflicts here?</div>
</div></div></blockquote><div><br></div><div>Basically cl.exe has very few long option names, so none of those prefixes conflict today.  -Wall exists, but it means something more like -Wpedantic.  Not a big deal.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>If we can make these work, I think we should stop. I think we should actually whitelist the set of flags that are supported in cl.exe mode so we find out if people want specific flags rather than things behaving weirdly.<br>

</div><div><br></div><div>If there are conflicts above, we could even consider renaming the clang flags to something that wouldn't conflict, but let's see if it's even a problem.</div></div><div><br></div><div>

<br></div><div>I do think there will be weird cases where users want to pass a very specific Clang flag that isn't in this set, but I think it's going to be *very* weird and I'm not worried about them having some hoops to jump through to get to it. So if we have to test for the flag in N different ways, or not, whatever. I'm OK with that.</div>

<div><br></div><div>I see three common things that we could use to make up the name for this: GCC-like syntactical conventions, Unix-like platform default mode, and the fact that Clang developers tend to view it is the primary Clang interface to the point that much of this commandline interface is shared between the driver and CC1. Using these I would come up with:</div>

<div><br></div><div>--gcc-style-flag=...</div><div>--unix-style-flag=...</div><div>--core-flag=...</div><div><br></div><div>I find the third one least bad. I find the GCC one confusing because I think it will be confused with when we are actually trying to be compatible with GCC...</div>
</div></blockquote><div><br></div><div></div></div></div><div class="gmail_extra">I think a double-dash prefix is best for the escape because there are no double-dash cl.exe options.  I like --core-flag= the best from the set above, although it seems to mean cc1 option at first glance, when it really isn't.</div>
</div>