[cfe-dev] alternate clang driver

[Reed Kotler]

On 10/21/2011 03:25 AM, David Chisnall wrote:
> On 21 Oct 2011, at 10:30, Jean-Daniel Dupas wrote:
>
>> I'm not sure writing a new driver from scratch is better than trying to externalize the configuration in the current driver.
>>
>> Is there anybody currently working on the universal driver ( http://clang.llvm.org/UniversalDriver.html ) ?
> No one's currently working on it (or, wasn't last week when I asked).  It's on my to-do list, but keeps getting pushed lower down by stuff I actually get paid for...
>
> David
>
> -- Sent from my brain
>
You will see that no matter how you do this, you will ultimately end up 
with an isomorphic solution to what I did.

You could try and put all the configuration variables in an XML file.

That will be like the data structures in my program but harder to 
understand when you want to configure things. You can't factor things 
then because it's just a big data file. If you do a lot of factoring, 
you won't be able to understand the file after a while without building 
some tool.

There are often some tricky things for a given installation, target, 
etc. and it's easier to fix this in the driver script than rebuilding 
the front end.

Dynamic scripting is more natural for handling installation issues than 
hard coding it in the compiler or even if you add reading some kind of 
external file.

Right now lots of people have to touch code in the same files for the 
driver, always a bad omen and indicator of design flaws and source of bugs.

What will happen is that over time, people will chip away at this 
problem and in the end you will have some half baked scripting language 
inside of the driver that does exactly the subset of python needed for 
my driver.

Clang should be a C++/C front end and that's it.

Let some natural scripting language worrying about gluing other pieces 
together.

My 2c.

Reed