[cfe-dev] MSVC compatible driver proposal

[Reid Kleckner]

On Wed, Jun 26, 2013 at 7:53 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Wed, Jun 26, 2013 at 3: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.
>
> Hmm, would cross-platform projects use the cl.exe-compatible driver?


Yes.  Consider the use case of generating a Visual Studio project file that
uses clang for diagnostics and or codegen, and wanting to control those
diagnostics.


> > 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.  :)
>
> It sounds like your mental model is that we have a "Clang driver", and
> a set of extensions for a "cl.exe-compatible driver". I think it might
> be a better perspective to think about this as a "g++-compatible
> driver" and a "cl.exe-compatible driver". I guess what I'm saying is
> that I don't like the name "-Xclang-driver" as a prefix for an option
> to the g++-compatible driver.


Would you prefer -Xgcc-driver?  I can see how -Xclang-driver would become
confusing, since they are both clang.  Maybe -Xdriver?  Honestly I don't
expect anyone will use the escape, but I wanted to propose it for
completeness and forwards compatibility if Microsoft adds a more severe
conflict for something core like -o.


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