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

Hartmut Kaiser hartmut.kaiser at gmail.com
Wed Sep 5 05:46:56 PDT 2007


Chris, 

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

I can't agree more with what you said.

Regards Hartmut




More information about the cfe-commits mailing list