[cfe-dev] alternate clang driver

[reed kotler]

On 10/21/2011 03:07 PM, Chris Lattner wrote:
> On Oct 21, 2011, at 2:47 PM, David Chisnall wrote:
>> On 21 Oct 2011, at 22:15, reed kotler wrote:
>>
>>> I don't buy the C++ is faster that Python argument. It's just a driver
>>> for a compiler! You could write it in Turing machine primitives and it
>>> would be super fast on a modern computer. It's not computing the
>>> strongly connected components of a terabyte sized graph.
>> The issue is start-up time.  It takes longer to launch the python process than it does for the entire compilation and code generation process to happen on small C files at -O0.
> I completely agree.  The startup time for python was a huge problem for the *first* clang driver, which happened to be written about Python.
>
> FWIW, Reed contacted me about this work back in May.  I encouraged him to contribute to improving the main Clang driver, and he wasn't interested.  It's perfectly fine for him to go off and do something different, but this work clearly isn't interesting to mainline clang development.  I don't see why we're still discussing it :)
>
> -Chris
>
I didn't say that I'm not interested to fix this in mainline clang .

I needed something right away and it was not practical to try and sort 
out all of this in mainline clang in a timely fashion.

It's not a small patch.

We need some  way to handle the scripting issues that come with 
installation.

Clang and LLVM have replaced the historical building of a different gcc 
compiler for each configuration and produce a single compiler but has 
not replaced much of what "configure" does in gcc.

There does not seem to be any consensus among the people on this list 
even as to the approach.

So I'm not interested to spend a lot of time making a 5k line or so 
patch that is likely to be rejected.

I did my driver and it solved all my problems and is very easy to 
maintain and understand.
As I refine this code I continue to understand the problems associated 
with this better.

I think all the same ideas could be implemented in the mainline clang.

This scripting language needs to be able to do many of the same things 
that perl and python does.

Yes, we could build our own and I could design something lightweight 
that fits in clang.

But before I would do that I would need to know that my hard work will 
not get tossed out.

At this point I think it's better for me to continue my prototype in Python.

Reed