From mboxrd@z Thu Jan  1 00:00:00 1970
From: rich-paul@rich-paul.net
To: Joe Buck <jbuck@Synopsys.COM>
Cc: rich-paul@rich-paul.net, martin@mira.isdn.cs.tu-berlin.de, egcs@egcs.cygnus.com
Subject: Re: Building binutils, egcs, gdb, etc
Date: Fri, 30 Apr 1999 23:15:00 -0000
Message-ID: <Pine.LNX.3.96.990401143540.3398D-100000@nitrogen.colossus.net>
References: <199904012229.OAA06642@atrus.synopsys.com>
X-SW-Source: 1999-04n/msg00022.html
Message-ID: <19990430231500.-BhiFyvA-oHAqaID33sRfknEBjuenNeewohgQklLb6M@z>

OK, this makes some sense ... here are my suggestions as to where to 
go from here:

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

Upsides:
	1) Each package would not have to maintain its own copy of these
		libraries.
	2) There could be meaningful versioning applied to these libraries
	3) One would download the libs first, and then whatever tools (s)he
		wanted to build, rather than downloading the libs with each
		tool.
	4) Bugs would be consistent
	5) The process could be disambiguated and demystified, so that perhaps
		to install a toolset you could get gdb, egcs, binutils, and base,
		and just do the following:
	tar -xzf /archive/base.tgz ( creates gnutools-baseversion/{libiberty,bfd} )
	tar -xzf /archive/egcs-core.tgz ( creates gnutools-baseversion/gcc )
	tar -xzf /archive/egcs-g++.tgz ( creates gnutools-baseversion/gcc/cp )
	tar -xzf /archive/binutils.tgz ( creates gnutools-baseversion/whatever )

	Note that this would require no duplicate files between these
	distributions, with ./configure, etc living in the base package.  It would
	also become obvious when you got a non-compatable tool ... if you unpack
	the thing, and it goes into gnutools-baseversion+1/whatever, you know
	that you need a new version of the base utils, and you can go get 'em.

Downsides:
	1) I'm not sure how this would effect people needing to add stuff to
	libiberty or libbfd.

	2) Things in libiberty would not be customizable to fit a particular
	application, they'd have to be generic. ( On second thought, maybe
	this is an upside? )

	3) Users would have to download one more package.
---
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 Thu, 1 Apr 1999, Joe Buck wrote:

> 
> > I found one referance that said that this would happen if
> > 'the sources were properly unpacked into the same directory'
> > but have never seen any description of how one would do that.
> 
> The key is that many of the GNU distributions are really subsets of
> one massive distribution that knows how to build everything (pretty
> much everything maintained primarily at Cygnus works this way).
> 
> Take a look at an unpacked egcs directory.  You see various files,
> together with directories:
> 
> INSTALL, config, contrib, etc, gcc, include, libf2c, libiberty, libio,
> libstdc++, texinfo, xiberty
> 
> Now do the same with the binutils distribution.  You see various
> files, together with the directories
> 
> bfd, binutils, config, etc, gas, gprof, include, ld, libiberty, opcodes,
> texinfo
> 
> If you look carefully, you'll see that many of these directories and
> top-level files are the same.  What's more, the top-level Makefile is
> prepared to build any set of tools underneath.  If you take the
> directories bfd, binutils, gas, gprof, ld, and opcodes from the binutils
> distribution and install them in the egcs tree, you can build everything
> (the compiler, linker, assembler, and libraries) in one shot.
> 
> Similarly, you can combine the gdb, mmalloc, readline, sim, and utils
> directory from the gdb distribution.
> 
> As I've said before, *warning*: if you combine distributions in this way,
> and they were released months apart, each might have been tested with
> slightly different libiberty, or bfd libraries: you can get something
> labelled, say, gdb-4.17 but if it has a newer bfd library, the bugs might
> be different (with some fixed and some added).
>