Re: Adding zlib to GCC

[Tom Tromey <tromey at cygnus dot com>]

Mark> This is an important issue.  Can the zlib people be enticed into
Mark> using configure?

I don't know.  Perhaps it is possible.  My guess is that it is
unlikely.  Why would they bother when they already have a scheme that
works for them and furthermore one that works on more platforms that
configure?

Mark> I see your point, of course -- that not including the zlib
Mark> source will make it harder for people to build GCJ, and it's
Mark> terrific that you've been careful to minimize changes.  But, I'd
Mark> still like to see these kinds of things packaged separately, and
Mark> have configure try to find the zlib already installed on my
Mark> system.  If it's not there, we could have configure spit out
Mark> "Can't build libgcj without zlib" and a message indicating where
Mark> to download it.

First, this sounds like a big problem to me.  It makes it *much*
harder to build libgcj.  For instance, not only are there several
required libraries (zlib, boehm-gc, libffi) and an unusual required
host tool (fastjar -- practically nobody will have this installed),
but in the case of both boehm-gc and libffi we need to have them built
in a certain way in order to work with libgcj.  Finally, libgcj needs
private headers from the GC, meaning that even users who manage to get
and install it will be faced with figuring out how to make them
visible to libgcj.  (Please don't say "fix libgcj".  If it were easy
we would have done it.)

Second, can we guarantee that all the gcc developers, especially the
c++ developers, will download and install all this stuff?  One of my
goals in getting libgcj into the gcc tree is to assure that various
gcc changes won't break libgcj builds -- as they have done
periodically for the last 6 months.  The complaint has been that it is
too hard to get and build libgcj -- but, ironically, if we don't
incorporate all these libraries into the gcc tree then it actually
becomes *harder* to build libgcj.  Right now at least there are just
two repositories to deal with, with relatively straightforward build
instructions (configure and build with the same options in both
cases).  Not putting things into the tree means we have to explain how
to build zlib (doesn't use configure), the GC (doesn't use configure,
requires specific magic options to work), and libffi (requires special
configuration to work with libjava).

Just to be clear, the issue here isn't about packaging in the sense
that Red Hat does it.  We provide an option to let the package builder
choose to use the system zlib if he prefers, and we assume that OS
packagers will do this.

Tom