[cfe-dev] MSVC compatible driver proposal

[Richard Smith]

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.

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

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

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