Re: Package's Infrastructure

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <37397906.B6BF6278@tls.msk.ru> you write:
[the usual libiberty not shared complaint]

This all comes from these gnu projects not having the same release schedule
at all, and some lack of coordination...

As far as libiberty goes, for instance, it's possible to build everything
with just one of those, as long as you are not using the specific system
which prompted a specific change which is somewhere, and not elsewhere...

This is something of a quality-of-implementation problem:
let's focus on cplus-dem.c.  It's fairly obvious to me that *both* ld and
gdb are sometimes not going to output anything helpful unless you use the
cplus-dem.c version that matches the C compiler you've been using.

That, plus issues of code reuse... I'm pretty sure that having several
branches of these very often means some small bloat (irrelevant), but
more importantly, some more work, as the same bugs are discovered again
and again, and fixed all over the place...

If you're really bent on sharing stuff, this means you have to follow 
development versions of all three projects, track the ChangeLog, find the
reasons behind libiberty of libbfd changes, and generally run stuff that
can be unstable from time to time (or write out patches for `stable' stuff
to enable it to run more recent binutils version without trouble.

No, I don't have any simple solution for that... and no, I don't volunteer
to coordinate such an effort...

just wanted to share my experience... just making the whole toolchain run
perfectly on a given OS  is not that easy.  I hope to be making small
contributions to that problem as time progresses.  Simplifying the build
of egcs/binutils/gdb is a post-1.2 release goal that I will be quite willing
to help with.