[cfe-dev] alternate clang driver

[Ruben Van Boxem]

Op 21 okt. 2011 00:58 schreef "reed kotler" <rkotler at mips.com> het volgende:
>
> 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.

That's the core difference between Clang and say, GCC: one Clang binary can
compile for all its targets (once it learns how to find headers and
libraries. It wouldn't make sense to hard code one target for a full-blown
cross-compiler. I do agree some kind of spec file based approach with system
specific directories is the way to go, so every client can easily point
Clang to its system includes.

>
> 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!
>
> It can't possibly work because many things can be installed in places
> that the front end could never know about.

It's not hard to teach it your setup, it takes about five minutes to cook up
a system specific patch, which you could use locally for the time being...
Until you or someone else bites the bullet and writes something better.

Ruben

>
> So it works for Apple where they can control where Xcode and other
> things get installed and will work for vanilla machines of other flavors
> where they can guess where things are.
>
>
>
> Reed
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111021/809e7d0f/attachment.html>