Re: proposal to fork the build-tools projects

[Tom Tromey]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

Tom> I have a preliminary configuration framework built this way, already.
Tom> I find it to be much simpler and it can do "everything" autoconf does.

How does it handle traces?

Tom> autoconf could itself be auditting installations and establishing
Tom> portable conventions for managing dependencies among packages.
Tom> It basically could replace package managers.

I think this is pretty unlikely.  Packages are different from what is
installed by `make install'.

For instance, you can't upgrade a package without also upgrading its
dependencies.

Or, a given source package is often turned into multiple binary
packages; it is common to only install a subset of these (e.g.,
install the runtime support but not the devel support).

Tom> Rather than users having to provide lots of `--with-package=PATH'
Tom> arguments, autoconf would be able to reliably find packages itself.
Tom> Rather than users having to read install instructions or web sites to
Tom> find out what antecedent packages are needed, autoconf could look at
Tom> the configuration data and tell you itself.

You don't need to turn autoconf into a packaging system to achieve
that.  Advances in this area already exist in the form of pkg-config.


My opinion is that if we can require something more than auto*, then
we should look at a new tool, not something based on sh+make.  That
will let us lift all the existing limitations, not just some of them.
This is what I'm working on now.

Tom