[cfe-dev] RFC: Clang driver redesign (round 2)

[David Chisnall]

On 8 Nov 2011, at 11:23, James Molloy wrote:

> "To GCC or not to GCC, that is the question"
> ============================================
> 
> +Doug Gregor, Miles Bader
> -Sean Hunt, Christopher Jefferson, Andrew Trick
> 
> There is differing opinion on the amount of GCC compatability clang
> should offer. A lot of examples and arguments have been given, but I
> see one conclusion - the driver should not be pinned to anything.
> 
> Depending on policy decisions, the user interface should be able to be
> changed with minimal effort.

GCC compatibility is definitely an advantage, but if the driver infrastructure is tidied up then it becomes a lot easier to add new GCC-incompatible drivers as well.  I think a lot of people would like to see a cl.exe-compatible one that can just be dropped into MSVC, and it might also be useful to provide a driver that had a less human-friendly set of options that is easier for an IDE to invoke (e.g. no defaults, everything explicitly configured and driven by the IDE's build description).

One other use case I forgot to mention: Objective-C runtime selection.  This is easy on Darwin, because Apple ships an Objective-C runtime and supports it for the duration of that release.  It's much harder on other platforms, where the runtime is a third party package and may support some variable subset of the features that clang supports.  The driver currently sets a load of codegen flags based on the runtime on Darwin, and it would be great if we could have runtimes on other platforms just drop in a config file that clang would automatically pick up and use to describe them.  This would also make my life easier when I add new features to the GNUstep runtime, as I could just flip a switch in the config file and have clang use them, rather than having to rely on users adding yet more flags to their make files...

David

-- Sent from my Apple II