[cfe-dev] MSVC compatible driver proposal

[Chandler Carruth]

This thread's chain of emails is somewhat tricky to reply to so I'll just
start fresh... Sorry for that...

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'.


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:

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

- Warnings using the '-Wsome-long-name' syntax: are there any conflicts
here?

- Language features using the '-fsome-long-name' syntax: are there any
conflicts here?

- Machine features using the '-msome-long-name' syntax: are there any
conflicts here?

- Debugging features using the '-gsome-long-name' syntax? Not sure we even
want this, but maybe: are there any conflicts here?

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.

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.


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.

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:

--gcc-style-flag=...
--unix-style-flag=...
--core-flag=...

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130626/c68b7992/attachment.html>