Re: Building binutils, egcs, gdb, etc

[rich-paul at rich-paul dot net]

Well, I guess I've come up with a plan of attack.  The first thing that
I'm going to do is a "liberty" project, which will attempt to create
a library that will provide the union of the functionality availiable in
the current libiberties, and be suitable for use as a shared library.

More generally, it will try to smooth over some platform differances,
providing common functionality in a way that will reduce the size of any
project that uses it be replacing code like

// example taken from xterm from xfree86, probably exists in some
// variation in expect and other projects.
#ifdef HAS_OPENPTY
	return openpty(...);
#else
	.. 70 lines of code to emulate openpty on differant systems
#endif

with always using openpty, and having it emulated in libiberty if it
is not provided by libc.  Basicly a general compatability library.

Hopefully use of this will spread to more or all opensource projects,
so they can remove their specific x-platform hacks and move them into
libiberty, reducing the amount of work requuired by configure by a great
extent, as well as the amount of preprocessor work required in client code,
and create a 'freeware common infrastructure'.

Once I get the basics from the existing libiberties, I'll be asking people
to try removing their various libiberties from various existing projects,
and testing with mine, and hopefully eventually removing libiberties from
their distributions entirely.

To those of you who have applied hacks to existing libiberties, please
let me know if there are any cases where you needed special functionality
rather than just fixed bugs in existing code.  Also, if somebody could tell
me where the original copy of egcs/libiberty came from, it would be a great
help.  Is there any repository of libiberty code that is synchronized?

Regards,
Rich Paul

P.S. I'm approaching this first, because it appears to be low-hanging fruit,
and applicable outside the projects that are it's source.  I'll probably
go ahead, when I have got this to a stable state, and attack libbfd, but that
requires a great deal of domain knowledge and possibly redesign, which I'm
not ready to do yet.

---
There is a party that  |  Libertarian Party  |  A victimless crime is
supports the right to  |  http://www.lp.org  |     a contradiction in 
free speach and        |    The Party of     |                 terms.
encryption!!           |      Principal      |  

On Fri, 2 Apr 1999 rich-paul@rich-paul.net wrote:

> You're right, on both counts.  But neither of these seems inconsistant
> with the requirements of current open-source projects ( my god, look at
> gnome ... I had to install gobs of packages ), and it seems to
> be worth pursuing from my point of view, as the Mozilla people would say,
> "For the good of the code".  One problem with the current approach besides
> package size and build time is that there is always for the potential for
> mismatches between binutils and gcc, and a programmer working on both
> projects would need to know that implementations of 'the same' function
> may vary between projects.  Not to mention that projects written with 
> binutils need to be read with gdb and visa-versa.
> 
> May I ask why these libraries are in constant flux?  It *seems* like their
> purpose is pretty cut and dried, but it could be that I do not understand
> the problem they solve well enough to know.
> 
> Regards,
> Rich
> 
> P.S.  I would be willing to maintain either or both of these libraries,
> if there is interest in changing to this method of distribution.  I've been
> looking to find a nitch in a good opensource project, and the project seems
> like a worthy one to me.  I'm a c++ guy, but I can do k&r, it's just like
> watching a movie in black and white.  <G>
> 
> ---
> There is a party that  |  Libertarian Party  |  A victimless crime is
> supports the right to  |  http://www.lp.org  |     a contradiction in 
> free speach and        |    The Party of     |                 terms.
> encryption!!           |      Principal      |  
> 
> On Fri, 2 Apr 1999, Martin v. Loewis wrote:
> 
> > > It seems to me like the best way to approach this situation would be to
> > > factor out the common parts into a seperate distribution.  This would have
> > > the following results ( in theory ).
> > [...]
> > > Downsides:
> > 
> > You forgot an important one
> > 
> >     4) Somebody would have to maintain it, over a period of many
> >        years, and be quite responsive to requests of the maintainers
> >        of the various packages, as well as to problems end-users have
> >        with it. Otherwise, maintainers will just grab a copy of the
> >        base package, integrate it, and modify it to their needs.
> > 
> > I don't see anybody stepping forward to do that. Of course, there is
> > also
> > 
> >     5) Packages are more difficult to install for typical
> >        end-users. End-users don't build the entire chain at one time,
> >        but they build gdb whenever a new version is release, and
> >        binutils whenver that is updated. They now download the source
> >        and compile. Under your scheme, they also have find out what
> >        else they need (i.e. the base package), and where they can get
> >        it.
> > 
> > Regards,
> > Martin
> > 
>