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

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

On 2/21/06, Robert Schwebel <robert@schwebel.de> wrote:
> > 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.

Hrm.  I'll add a script that clears all the variables, and source
that from the demo scripts, maybe?

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

I started when I was at Ixia, where we had embedded systems that used
sh4, ppc405, and ppc750.  Now I'm at Google, and we mostly just use
mainline desktop processors (unless you count the tivo's we run at home :-)
We chiefly need to track newer releases of gcc, and binutils too if
they speed up ld.
We have to support a range of glibc's; it's not practical to require
my users to update glibc.   I fondly remember my embedded days, and
I want to make sure crosstool remains useful for embedded developers.
I'd also like it to be useful for ISV's trying to build for every CPU
type supported
by Linux.

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

Right.  Well, for crosstool, it's to support not just one project, but many.
And some projects simply must continue to use old glibc's.

> I can live very well with posting patches - that's what we do in lots of other
> projects as well.

Great.  Can you post a trial patch for inclusion in crosstool-0.41?

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

Heh.  Have a look at regtest_run.sh.  It simply uses scp and ssh.
It assumes a few things about the remote build machines, and
it probably needs editing before anyone but me can run it, but it
handles details like machines being different speeds, machines
going down, etc.

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

What I actually do happens in the four days before a release.
And there's no particular value to it being seen before release, I think.
If a problem shows up, I will happily spin another release.

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

Agreed.  I thought the mailing list was how we were going to
coordinate efforts.  Basically, I think it's not a tools problem;
we have all the tools we need to coordinate.

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

I should have said "I like source trees that have tastemasters;
i.e. I like Linus's approach more than I like gcc's approach."

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

Thanks!
- 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