[cfe-dev] MSVC compatible driver proposal

[Reid Kleckner]

On Wed, Jun 26, 2013 at 10:12 PM, Chandler Carruth <chandlerc at google.com>wrote:

> This thread's chain of emails is somewhat tricky to reply to so I'll just
> start fresh... Sorry for that...
>
> I think we need to admit that there is some preferred Clang set of options
> and option syntaxes. They may be chosen to be consistent with GCC in some
> ways, but they're not actually compatible. The most frequently cited here
> is actually a case in point: GCC doesn't support -fcolor-diagnostics, so I
> don't think we can sensibly call it '-Xgcc-driver=-fcolor-diagnostics'.
>
>
> But let's simplify this: we really don't need to support *all* of the
> existing command line syntax when operating in a cl.exe compatible mode.
> Instead, let's focus on what the important use cases are for user provided
> flags that might be useful to support across platforms:
>
> - High level driver flags like '--coverage', '--target', .... I think
> these are OK as I don't think MS supports double-dash syntax, or if they do
> I doubt many use it.
>

Yep, there are no double-dash flags, or at least I can't find them.


> - Warnings using the '-Wsome-long-name' syntax: are there any conflicts
> here?
>
> - Language features using the '-fsome-long-name' syntax: are there any
> conflicts here?
>
> - Machine features using the '-msome-long-name' syntax: are there any
> conflicts here?
>
> - Debugging features using the '-gsome-long-name' syntax? Not sure we even
> want this, but maybe: are there any conflicts here?
>

Basically cl.exe has very few long option names, so none of those prefixes
conflict today.  -Wall exists, but it means something more like -Wpedantic.
 Not a big deal.

If we can make these work, I think we should stop. I think we should
> actually whitelist the set of flags that are supported in cl.exe mode so we
> find out if people want specific flags rather than things behaving weirdly.
>
> If there are conflicts above, we could even consider renaming the clang
> flags to something that wouldn't conflict, but let's see if it's even a
> problem.
>
>
> I do think there will be weird cases where users want to pass a very
> specific Clang flag that isn't in this set, but I think it's going to be
> *very* weird and I'm not worried about them having some hoops to jump
> through to get to it. So if we have to test for the flag in N different
> ways, or not, whatever. I'm OK with that.
>
> I see three common things that we could use to make up the name for this:
> GCC-like syntactical conventions, Unix-like platform default mode, and the
> fact that Clang developers tend to view it is the primary Clang interface
> to the point that much of this commandline interface is shared between the
> driver and CC1. Using these I would come up with:
>
> --gcc-style-flag=...
> --unix-style-flag=...
> --core-flag=...
>
> I find the third one least bad. I find the GCC one confusing because I
> think it will be confused with when we are actually trying to be compatible
> with GCC...
>

I think a double-dash prefix is best for the escape because there are no
double-dash cl.exe options.  I like --core-flag= the best from the set
above, although it seems to mean cc1 option at first glance, when it really
isn't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130626/1c4c470e/attachment.html>