[cfe-dev] MSVC compatible driver proposal

[Reid Kleckner]

I'd like there to be a cl.exe compatible clang driver.  I think the best
way for this to work is to have the existing clang driver detect when it's
being invoked as cl.exe, similar to how clang++ vs. clang works today.  For
testing, there should be a -ccc-msvc option which turns on the same
behavior.

Some relevant past discussion on this topic:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html

The priorities for the driver should be, in order:

1. Drop in compatibility with MSVC
2. Compatibility with the existing clang driver
3. Don't change the meaning of existing gcc-style driver command lines (an
argument with a / prefix is an input path, not an option)
4. Avoid -cc1 option explosion by aliasing MSVC options to gcc options as
much as possible

I think #2 is important so that cross-platform projects (like LLVM) won't
have to spell clang options like -fcolor-diagnostics or -Wc++11-extensions
twice.

It's important to know that there are a few conflicts with MSVC like -MD,
-MT, and things like -Zi where clang accepts -Z as a joined option, so
there needs to be a good solution for disambiguating them.

Previously people have discussed using the slash prefix to disambiguate
between the MSVC and clang meanings, but since cl.exe accepts both - and /
prefixes for all of its options, I don't like this approach.  There are
probably many Unix expats out there on Windows consistently using
dash-style option prefixes everywhere, like me.

I think clang should give a higher precedence to all MSVC options before
falling back to gcc style options.  To resolve conflicts, there will have
to be an escape flag.  I propose -Xclang-driver, which is similar to
-Xclang, except that it gets interpreted by the driver.  Hopefully
Microsoft never adds an -Xclang-driver flag.  :)

Going forwards, Microsoft will probably add more flags to cl.exe.  If they
do and they conflict, we should value drop in compatibility above backwards
compatibility and interpret the option as MSVC does, requiring users to use
the escape if they need the conflicting option.

I've attached patches for LLVM and clang to start implementing this.
 They're pretty rough, but I really want to get something committed and
iterate on it, even if I back up and completely rewrite with a separate
OptTable.  I've been testing the driver by renaming clang.exe to cl.exe and
putting it in the cwd before running MSBuild.  It currently fails due to
UTF-16 response files and -Fo takes an output directory which needs -cc1
logic.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130626/4b472dbd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse-option-flags.diff
Type: application/octet-stream
Size: 5208 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130626/4b472dbd/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-cl.diff
Type: application/octet-stream
Size: 24214 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130626/4b472dbd/attachment-0001.obj>