[cfe-dev] alternate clang driver

[Jean-Daniel Dupas]

Le 21 oct. 2011 à 00:56, reed kotler a écrit :

> On 10/20/2011 03:32 PM, Douglas Gregor wrote:
>> On Oct 20, 2011, at 3:00 PM, reed kotler wrote:
>> 
>>> Hi David,
>>> 
>>> I'm not really trying to sell people on another tool.
>>> 
>>> It's there if someone else wants to use it.
>>> 
>>> I found the clang driver to be overly complex and it was slowing down my
>>> development and to me it should have taken about 10 minutes to set up a
>>> new port and instead it involved lots of study and doing lots of
>>> hardcoding regarding specific directories to search and may other such
>>> things in the compiler which I find fundamentally wrong.
>>> 
>>> With my driver, I could do new ones in no time and make simple install
>>> scripts so it can be configured for specific users machine.
>> 
>> It often looks easier to hack up your own code for a specific case rather than generalizing existing code to incorporate the case you care about. But in my experience, it's rarely the right course of action. Inevitably, you end up solving the same problems that the existing code already handled, and spent more time re-inventing wheels than you would have spent in generalizing the wheels that work.
>> 
>> It would be awesome if it were easier to incorporate new ports into the Clang driver. We won't get there if everyone hacks up their own Python script instead.
>> 
>> 	- Doug
> Well, it's my opinion that a lot of the driver functionality does not 
> belong in the clang front end.
> It should be taken out and a tool like what I wrote should be used for 
> that functionality. Many compilers do just that, especially ones that 
> work with many targets/hosts , like the MetaWare compiler for example.
> 
> I did not launch on my effort without first thinking about this a lot.
> 
> The root of the problem is that clang does not use configure to set it's 
> host/target and other things in stone.
> 
> I think that is a good idea but then how do you configure things.
> 
> Right now it's done by hardcoding the world in C++ code in the front 
> end, including things like all the specific version numbers of gcc.
> 
> Gag me with a spoon!


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 ) ? 


-- Jean-Daniel