[cfe-commits] Patch to make clang compile and work on Windows using MSVC8
Chris Lattner
clattner at apple.com
Tue Sep 4 23:34:47 PDT 2007
On Sep 4, 2007, at 7:42 PM, Steve Naroff wrote:
>> If there are extensions supported these should be enabled
>> explicitely if
>> needed. In this context I'ld report an _error_ on "backslash and
>> newline
>> separated by space" and allow to bring that down to an (pedantic)
>> warning
>> using a special --allow_gcc_extensions switch only. But YMMV...
>>
>
> From my perspective, this is a policy decision (that I don't have a
> strong opinion on). In general, I don't think a low level tool
> (like clang) should be in the business of setting policy. Policy
> can be set by local build systems (make, jam, ant, etc.) and
> integrated development environments (Xcode, etc.).
I completely agree with Steve, but I'd phrase it differently. How
about this:
1. The libraries should provide the mechanisms that clients can use
to enforce the policies that they want. It should be possible to
build a tool that defaults to gcc compatibility, and it should be
equally possible to build a tool that is 100% strict. This means
that policy decisions from the clients should not be built into the
libraries. I believe we do this fairly well today, but we may be
missing something.
2. Based on these libraries, we can build a series of clients using
this for various purposes. The current clang driver is designed to
be GCC compatible where possible. This includes command line options
(even horrible ones) and defaulting to enabling GCC extensions etc.
3. Going forward, I'd like to define a "less horrible" command line
interface to the libraries and standardize *it*. Not only should it
default to warning or erroring on all extensions by default, but it
should have completely different command line syntax than GCC. Of
course, the point isn't to be different, the point is to not be
constrained by compatibility and do things right/consistently.
In practice, these design points are all useful, but their priorities
vary based on the people you talk to. #1 is useful for someone
hacking on a specific tool (e.g. a refactoring tool) and to support
#2/#3, #2 is useful for someone who wants to drop clang into a
makefile system that is already compatible with (or only works with)
GCC, and #3 is useful for people trying to actually build portable
software and want the compiler to help them do that (for example,
llvm itself falls into this category) and is already portable to
different compilers with different options.
In practice, we (the apple folks) are investing most effort in GCC
compatibility right now, mostly because this is a pragmatic goal for
us. However, all of the work going into the library should support
different clients, and you should be able to build a new executable
(replacing just the code in the Driver directory) that sets any
policy that you want. If you have a strong desire to work on this in
the short-term, please go for it!
-Chris
More information about the cfe-commits
mailing list