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

[Robert Schwebel <robert at schwebel dot de>]

On Tue, Feb 21, 2006 at 07:53:33AM -0800, Dan Kegel wrote:
> 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.

They easily leak in from the calling environment, you have no real
"central point of definition". But it's an implementation detail. 

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

Could you tell me more about what's your reasons for doing the crosstool
stuff? I'd like to learn more about your aims, just to understand what's
driving the development on your side. 

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

In the main PTXdist repository: 

https://iocaste.penguin.de/viewsvn/ptxdist/trunks/ptxdist-0.10-trunk/patches/crosstool-0.38/generic/

user: guest
pass: guest

Sorry, I thought that you had followed the PTXdist list, otherwhise I
had told you more explicitely. 

> > - 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.

No intention to blame anyone. It's just a list of things which make
problems for us. 

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

Sorry again, thought you'd read the ptxdist list. 

> > 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.

I've followed that road with PTXdist as well for quite some time. The
question is, what are the goals for a project. For PTXdist, I decided
that I want to have reasonable toolchains for the architectures we
support, which is ppc (603e, 405), arm (pxa2xx, imx, h720x, ns9360,
netX) and generic x86-32 at the moment, probably more to come. 

We have supported customers who are working with older PTXdist versions,
but our policy is clearly to do feature development only on top-of-tree.
So the old stuff works with the old versions, the new ones only support
something like "latest releases of a series", e.g. 3.3 or 4.0 etc. My
personal impression is that it is a waste of time to spend hours and
days into backporting old fixes for problems which are long solved in
newer versions of the same project.  

But that's definitely a question of what to achieve and a question of
personal taste. 

For glibc, the question is which targets can _not_ be supported with
glibc-2.3.6, but can with earlier versions? 

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

Ok. 

> It's clear that you're itching to be able to commit patches to
> crosstool yourself.

It doesn't matter who is able to really commit to the master tree, I can
live very well with posting patches - that's what we do in lots of other
projects as well. It's just that quick hacks are done much faster than
solving things properly for upstream, and I only invest the time to do
so if there is a chance that my codebase isn't totally out of date once
the patches are out, and there is a chance that patches are being
accepted upstream. 

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

Would be an option. How do you spread the build process over the
machines? Are you using distcc or something like that? 

> 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.

File number isn't really a problem for svn. Things like buildlogs IMHO
don't really belong into a release, they are better being uploaded to
some website. 

> >    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.

Which isn't really a problem. It's more about making visible what you
actually do, _before_ a release is out. 

> > 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.

The question is if we are able to manage to have _one_ community for
this toolchain building stuff, or everyone doing his own thing, having
only his little part of the puzzle on focus. It would be a shame, as no
one of these build scripts out there ever reached critical mass. 

> I will never accept a procedure that lets random people check in
> patches; crosstool QA is hard. So access control has to be tight.

No problem with that, it can be managed. 

> And I'm no fan of slow servers; is Berlios really better than
> Sourceforge? 

It looks better to me, but I havn't much long term experience. 

> But the main thing that would convince me would be an automated weekly
> build.

Ok, so let's fire up the cpus :-) 

For the moment I'm just starting to work with the repository, to do our
stuff in public. If you want to join, go ahead, it would be great. If
not, I'll just follow your releases there and try to catch up. 

It's just to make it absolutely clear that there is no intention to
fork, but to support the very good work you did with crosstool. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9


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