Re: Adding zlib to GCC

[Geoff Keating <geoffk at cygnus dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

> The problem is that you only want to make that branch if the
> components are relatively stable.  You can't branch GDB, for instance,
> if BFD is crashing all over the place at the moment.  The more stuff
> we pile into one repository, the more interdependent we become.

This is because BFD is shared between GDB and binutils.  We could fix
that easily by forking BFD, one fork especially for GDB and one fork
especially for binutils.  Of course, that would double the amount of
work required to maintain it, as everything would now need to be done
twice.

> The whole point of component architectures is to provide stable,
> independent components.  Something like zlib should be a different
> component, and it should be used unmodified in GCC.  If it needs
> modification, we should work to put together a new zlib release, and
> we should use that release.  Trust me -- I'm finding it very hard to
> get a GCC 3.0 release done, largely because I'm waiting for people to
> stabilize various pieces of the tree, and complete little bits of
> implementation.  The more intertwined things are, the harder that will
> be.

The questions of whether we modify zlib once it's in our tree, or
whether we put it in at all, are different and mostly independent.  I
wouldn't support GCC having its own private zlib version, that sounds
like trouble waiting to happen.
-- 
- Geoffrey Keating <geoffk@cygnus.com>