[cfe-commits] r52417 - /cfe/trunk/utils/ccc
hs4233 at mail.mn-solutions.de
Wed Jun 18 00:00:16 PDT 2008
> 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
The current "clang" compiler driver could stay, as a test-bed and
example (on how to use the llvm-clang-library).
More information about the cfe-commits