Re: Adding zlib to GCC

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Geoff" == Geoff Keating <geoffk@cygnus.com> writes:

    Geoff> dejagnu and gperf are tools used on the build system.  You
    Geoff> use both of these to build gcc.  However, zlib is like
    Geoff> libiberty

I know.

    Geoff> I detect confusion here.

No, I'm really not, I do understand what's being built when.  I just
don't care. :-)

You do tell me I am confused a lot though, even when I am not. :-) 

    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.

That's not relevant.  Here, for example, is how one very large company
builds pretty good compilers:

  - Back-end guys and front-end guys (guys is meant to be
    gender-neutral here) sit down and agree on interface
    between back-end and front-end.

  - Back-end and front-end get built, which clean interface.

  - Version 1.0 is released.

  - Front-end and back-end are frozen.

  - Back-end and front-end continue to be developed.

  - Front-end guys link against the 1.0 back-end, back-end guys link
    against the 1.0 front-end.

  - After a while, suppose the Fortran compiler team decides to
    release a new version.  They do this:

      - Is a new version of the back-end ready?

      - If so, does it make things better?  Does it make things
	worse?  If it makes things worse, try to get the back-end
	guys to fix the problems.

This method breaks many of the dependencies between back-end and
front-end.  Even a wild set of changes in the back-end causing massive
instability do not impact the front-end guys.  The Fortran guys don't
impact the C++ guys.  The up-front design effort resulted in a *much*
cleaner interface between the front-end and back-end than in GCC.

Obviously before the back-end guys can say "this is back-end 1.1" they
have to verify that it works with all the front-ends.  But the
front-end guys don't constantly rebuild the back-end and have; they
just build it once, from the 1.0 tarball-equivalent.

Obviously, it sometimes necessary to incorporate an intermediate
version of the back-end into the build process if there is a back-end
fix that is required for development of the Fortran 1.1 front-end,
say.  So, I am not claiming the world is that simple.

However, it is not that far from that simple, in practice.  The fact
that this is difficult to do in GCC reflects a design failure in GCC,
and one that we should be working to address.

It is tempting to think that those proprietary guys don't have
anything to teach us bazaar hackers about building software, but
that's foolish.  We should admit that actually those kinds of big
software organizations have turned out an awful lot of high-quality
software, and we should try to see how they do it.

    Geoff>      Likewise, if your program uses small GNU software

Are these things GNU packages?

I think the release tarball issues are pretty much orthogonal, though.
I think it's reasonable to have some release engineering process that
involves including some other packages.  I agree that including these
things in the tarball is OK -- but I still think that we should try to
use an installed version of the libraries, if that's possible.

You seem very convinced that you are right about what source should go
in CVS.  I am not as convinced that I am right about that -- in fact,
I see strong arguments on both sides.  As I said before, that
indicates to me that I should defer to you.

However, I will raise a ruckus if we are pulling in many more
libraries.  I do not want to see `libtiff' in our source tree when
some language has builtiin spport for faxing documents. :-)

I do believe I am right about the larger software engineering issues.
Our current process does not scale well.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com