Re: crosstool-0.40 released: gcc-4.1 rc1 support

["Dan Kegel" <dank at kegel dot com>]

On 2/20/06, Robert Schwebel <robert@schwebel.de> wrote:
> - The whole "add-more-little-unkomfortable-scripts" mechanics sucks, as
>   well as the spagetti code style of the main scripts. There are no well
>   defined interfaces between the building blocks (passing stuff by
>   environment variables is simply plain uggly). The question is
>   how to address this: when we talked about the uClibc stuff some time
>   ago you sayed that you'd like to see this integrated in a more
>   function- or several-scripts-like method.

Integrating the NPTL or uClibc support might be a good opportunity
for cleaning that up a bit.  I'm not sure why you don't like using
environment variables, though; they're effectively named parameters,
and that's very convenient and robust.

> - We really need NPTL support for our toolchains now. Crosstool's NPTL
>   activiy has stuck, there is not more serious support for it in 0.40
>   than there was in 0.38, which is roughly half a year old. Modern
>   systems, for example with Preempt-RT need NPTL, so we need a roadmap
>   how to get support for it.

I think I'll need it this year, too.  I don't have a plan yet.

> - We really need uClibc, not now, but in the near future.

A lot of folks do.

> The patches
>   we currently have in PTXdist against crosstool are not maintainable.

Where are they?

> - Softfloat on ARM isn't solved.

Sure, but that's not my fault, as somebody else pointed out!
Hopefully gcc-4.1 will help here.

 > - Managing out-of-tree patches against crosstool is a mayor pain in
>   the You-Know-What. So what we currently do in PTXdist to support
>   features which fix crosstool problems cannot be handled any more.

You haven't really been informing me of these patches, so I'm not
sure what they are...

> - I'm not sure what is your intention of supporting _all_ gcc/glibc/...
>   versions out there, and I doubt that this is maintainable. ...

I can at least delete the old dated snapshots,
and it's probably reasonable to remove all but the latest
two micro releases of gcc (e.g. when gcc-3.3.6 comes out,
remove gcc-3.3.4 and earlier).

>   Always combinded with the latest glibc (2.3.6).

Now, that's not at all reasonable.  glibc is a nasty beast to update,
and people have to deal with their existing targets.

> - The development process is not open enough. We are usually working
>   very closely together with upstream people, and in fact PTXdist is
>   mainly about making upstream better by supplying the relevant patches.
>   People don't have a chance to jump on your train when you only release
>   every half a year. It doesn't make sense to send you intrusive patches
>   against six month old codebase without knowing what you have
>   internally.

I can clear that up - I do very little crosstool development between releases!

It's clear that you're itching to be able to commit patches to crosstool
yourself.  Are you also willing and able to run the build matrix script?
It takes a *lot* of CPU to run.  It would be totally impractical if I didn't
have dozens of machines to run it on.   (And yes, reducing the number
of supported versions will help massively here.)

> 1) I've opened a crosstool project on Berlios, which is here:
>    http://developer.berlios.de/projects/crosstool/

I have mixed feelings about using svn for the thousands of little files
in crosstool.  I would like to keep the buildlogs out of svn, for instance,
and the demo scripts should be generated.  Maybe I can clean out
the attic a bit for crosstool-0.41.

>    We could open a "Dan's Maintainance Trunk" which can hold exactly
>    what you do at the moment, without intrusion by others, but
>    visible to the public even between releases.

Since I don't do any crosstool development between releases,
that would be a pretty quiet branch.

> 2) I'd like to see some public discussion about how the main crosstool
>    scripts have to be structured. That probably means clean interfaces,
>    separated scripts or functions, config frontend.

Feel free.

>    The svn on berlios would give us the possibility to make a prototype
>    for that in a branch, without disturbing your work, and involve
>    people from the community.

svn is most definitely not needed for that.  Several people have
already posted simplified crosstool scripts.  That these scripts
were not adopted has absolutely nothing to do with whether they
were in svn.

> Would you accept such a procedure? It does only make sense if you'd
> really use it.

I will never accept a procedure that lets random people check in
patches; crosstool QA is hard.  So access control has to be tight.
And I'm no fan of slow servers; is Berlios really better than Sourceforge?
But the main thing that would convince me would be an automated
weekly build.
- Dan

--
Wine for Windows ISVs: http://kegel.com/wine/isv

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org