[cfe-commits] Patch to make clang compile and work on Windows using MSVC8

[Chris Lattner]

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