[cfe-commits] r52417 - /cfe/trunk/utils/ccc

[Holger Schurig]

> I think before we start adopting a new driver, we need to
> decide our design goals going forward.  Is it just to make a
> drop-in replacement for gcc, or do we want something more?

As a (potential) user, I'd like the drop-in approach. Even Intel 
made it's icc eventually be a drop-in for gcc.

PRO: allows usage of clang as a drop-in in almost any open-source
and lots of closed-source project

CON: if we decide to be drop-in-compatible, we *have* to be 
compatible. We're married to gcc's command line handling. And if 
there is some cruft from 20 years ago, it would be not simple to 
get rid of that.


However, I'm not sure if this additional compiler driver should 
be written in perl or python. Make clang a library and let 
compiler driver directly run the needed things. Saves fork 
times :-)

The current "clang" compiler driver could stay, as a test-bed and 
example (on how to use the llvm-clang-library).