<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>
<br></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><br></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><br></div><div>I find using either '--' or '-X' as a prefix fine, I'm not too fussed about the subprocess traditional role of -X but I don't care much.</div></div>