[cfe-dev] MSVC compatible driver proposal

[Reid Kleckner]

Code comments can go on the phab issues or to the commit list threads:

http://llvm-reviews.chandlerc.com/D1048
http://llvm-reviews.chandlerc.com/D1049


On Wed, Jun 26, 2013 at 6:56 PM, Reid Kleckner <rnk at google.com> wrote:

> 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/a93547ec/attachment.html>