Re: proposal to fork the build-tools projects

[Tom Lord]

       > It could be that we should tell people to use Bash to build
       > GNU packages if their native shells have trouble handling the
       > job.  That would be a smaller change and perhaps worth doing.


How is `bash' built?


        >> You need to be able to compile the bootstrap packages in minimal
        >> environments, in order to get a very basic GNU environment.

        > I don't think we should do this at all.  The smallest version of the
        > GNU system need not be "minimal", and making it so would be extra
        > work, so we should not.

Well, then I think you agree with me and you should conclude that
forking as I've suggested is the right thing to do.

GNU ALREADY has this property that you dislike wasting effort on, and
it does result in wasted effort (it appears to me).  My proposal to
fork the build tools is a way to eliminate the wasted effort without
purturbing the useful structure it currently preseerves.

The core *utils package and the compiler are already maintained with
relatively strict portability requirements (for example, that they can
be compiled with a variety of compilers, shells, and implementations
of make).   The maintainers have been doing this for years, and it's
very valuable.   That's _not_ wasted work -- it's how people are able
to migrate to the wider world of GNU software.

However, those portability requirements from the core packages turn
into requirements for the build tools (the auto* tools especially).
So, for example, (I gather from this list), there are parts of
autoconf that can't get away from m4 and that can't use shell
functions.  There are parts of automake that can't assume the featuers
of (extremely portable) GNU make.  _That_ is the source of the extra
work that can be eliminated.

It turns into extra work because of all the other apps people are
working on that put demands on the build tools.   Any effort put into 
making the build tools work better for those apps has to pay an
"effort tax" by designing a solution that doesn't disturb the
portability of *utils.

The way to _save_ work is to stabilize a fork of the auto* tools for
the *utils and compiler, and create an easier-to-change fork for
everything else.  The easier-to-change fork can, at least, assume it's
running with a good shell and the *utils.

-t