Re: Adding zlib to GCC

[Geoff Keating <geoffk at cygnus dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

> I do not believe it practical to add too many more languages and
> libraries to GCC and still require everyone to build everything and
> test everything all the time.

I too am concerned about this.

> I think we should instead be trying to move towards stable
> components -- let the back end folks hack on the back end for a
> while without impacting the front end folks, let the C++ folks hack
> without impacting the Java folks, and so forth.

However, I don't see this is the solution.  I don't believe, for
instance, that you can make changes to backends without testing them
with the full (C/C++/g77) testsuite.  There are too many corners that
are only exercised by one of the frontends.

> The more we intertwine, the more poorly we scale.  Richard Henderson
> and I have an ongoing debate on this issue -- Richard does not agree
> with me.  Since Richard is usually right, but since I still believe
> what I believe, I am worried. :-))

IMHO, the real problem is not scaling, but build time.  We can handle
a significantly higher change rate than we have now, but a significant
increase in build times is much harder to deal with.  It'd be annoying
to be working with my 4-way 64-bit workstation with 4G of RAM in five
years and still have to wait 3 hours for a build&test.

> I'm disappointed that these libraries are as hard as you say to
> configure, build, and install correctly.  I would like to download and
> install zlib, or the collector, just once -- not rebuild it every time
> I have to rebuild GCC.

You can do that now with the target libraries.  You don't have to
rebuild libio or libstdc++, if you have them installed.  Just delete
them from your source tree.  I think you can even install libiberty.
I know you can install the "other" target libraries, newlib and
libgloss, because that's how the automated tester works.

>  Perhaps more importantly, I really would like
> to avoid the temptation to "just make a change or two right here" that
> are convenient.  I think disincentivizing that is worth a lot.
> 
> I'm not sure what to do.  Do you think it is impractical to put this
> stuff in the infrasructure directory, like some of the other
> components that we use with GCC?  For example, dejagnu and gperf are
> distributed that way.  I think that would be a cleaner solution.

I detect confusion here.

dejagnu and gperf are tools used on the build system.  You use both of
these to build gcc.  However, zlib is like libiberty; it will be used
on the host and target systems [although not, thank goodness, on the
build system---did Canadian crosses ever get fixed?].  It probably
even needs to be multilibbed, although I could live without that for
the moment :-).



Finally, one important point.  Put them in CVS, maybe, maybe not.  But
it's a firm GNU policy that they do go in the release tarballs:

     Likewise, if your program uses small GNU software packages like
  regex, getopt, obstack, or termcap, include them in the distribution
  file.  Leaving them out would make the distribution file a little
  smaller at the expense of possible inconvenience to a user who doesn't
  know what other files to get.

Please do do this, there's nothing worse than downloading a huge
package and discovering you have to get library 'foobar' which you
didn't even know existed and turns out to be 36k of source.
-- 
- Geoffrey Keating <geoffk@cygnus.com>