[cfe-dev] MSVC compatible driver proposal

Wed Jun 26 17:48:18 PDT 2013

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

> On Wed, Jun 26, 2013 at 5:03 PM, Reid Kleckner <rnk at google.com> wrote:
> > 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 seems like it should be possible to teach the build system to add
> the -Xwhatever in this case. Depending on how many conflicting options
> we have, cross-platform code may not be able to get away with using
> g++ driver options for the cl.exe driver anyway.
>

What I have in mind right now is CMake, where every user pretty much does
their own ad hoc flag checking and munging.  Every CMake user would have to
say add_cflag_if_supported("-fblah") / add_cflag_if_supported("-Xescape
-fblah"), or it would be in some 'if clang' block.

One thing we could do to cut complexity here is forget about supporting the
long tail of gcc driver options and just focus on a short-list of groups
like -W, -f, -m, and maybe others.

 Maybe we should have some begin/end markers for g++ driver arguments
> so we don't have to add -Xwhatever before each one.

I could see begin and end markers working, but I don't like the
statefulness that they add to the flags.  It's already hard to read ld's
--start-group --end-group flags.

> >> > 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.
>
> They're both drivers, too, so -Xdriver doesn't seem quite right.
> Thoughts on -Xgcc for this case, and -Xcl.exe for the opposite case? I
> have reservations about this, since -Xfoo is currently used to mean
> "use these options when running the foo subprocess", but equally we
> can interpret it as meaning "here's an option in foo's option syntax".

-Xgcc doesn't seem right since we invoke do invoke gcc to do things like
assemble for mingw.  How about something terribly explicit like
--escaped-clang-args="multiple args here"?

> >> > 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?
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130626/7e7c1dc6/attachment.html>