Re: proposal to fork the build-tools projects

[Tom Lord]

This answers questions and objections raised by peter_e and rms, and
points out that the package managers used by various distributions are
doing a job that would be better done by the build tools themselves.



        peter_e:

        > But what were your thoughts on Autoconf?  Autoconf isn't
        > going to benefit greatly from assuming, say, a strict POSIX
        > environment.


One huge advantage of assuming a POSIX shell is that you no longer
need m4.  That should make it easier for people to understand and
debug the code, as well as to write new tests and other extensions.
It also gets rid of the minor headache of having to compile your
configure script before distribution and the less minor headache of
users sometimes having to (find the right version of autoconf and)
compile the configure script.

I have a preliminary configuration framework built this way, already.
I find it to be much simpler and it can do "everything" autoconf does.
(By "everything" I mean that the preliminary architecture is in
place -- it does not have replacements for all the specific tests that
autoconf has and it doesn't have code to handle cross-compilation).
(The `package-framework' package at ftp.regexps.com).


        rms:

        > lord:
        >> Supporting [bootstrap package] builds is an entirely
        >> different problem from supporting the builds of everything else.
        >> One fork for those bootstrap projects -- another for everything else.
        > 
        > This conclusion does not follow.  


You need to be able to compile the bootstrap packages in minimal
environments, in order to get a very basic GNU environment.  This is
mostly an exercise in achieving portability against very harsh
constraints.

You need to be able to compile and maintain a complete system from all
of the other packages.  This _should be_ mostly an exercise in
managing dependencies among the packages themselves, and in managing a 
robust, auditted install.

autoconf was designed for the former, but is being applied for the
latter.

Because autoconf was not designed with maintaining complete systems in
mind, every single distribution adds a "package manager" whose job is
to audit what is installed and manage dependencies among installed
packages.  There is more than one package manager around; they are
mutually incompatible; they don't gracefullly handle installing
unrecognized apps (those without spec files) from source; and they are
extra work for maintainers.

autoconf could itself be auditting installations and establishing
portable conventions for managing dependencies among packages.
It basically could replace package managers.
Rather than users having to provide lots of `--with-package=PATH'
arguments, autoconf would be able to reliably find packages itself.
Rather than users having to read install instructions or web sites to
find out what antecedent packages are needed, autoconf could look at
the configuration data and tell you itself.


        > Given that we are trying
        > to handle "everything else" anyway, perhaps it is easies to
        > do what we are doing, and handle the bootstrap projects with
        > the same autoconf and automake.

That seems unlikely.  Even just the awkwardness of using m4 to
work-around broken shells makes hacking autoconf less than pleasant.
I wouldn't want to add much by way of new features to the existing
code base.

-t