Russell Nelson writes:
> Russ Allbery writes:
> > autoconf most certainly is not monolithic. It *generates* a monolithic
> > shell script, precisely because that shell script is performing
> > workarounds for things that Dan doesn't deal with and is producing output
> > in a form that Dan doesn't use.
>
> Right. Dan doesn't do it that way because it's wrong. Dan's insight
> is simply that make consults a database called a filesystem. So
> instead of having a shell script create its own database, and from
> that a Makefile, he has a fixed Makefile create database entries. As
> a consequence, ``making'' a package consists of running make, instead
> of:
>
> libtoolize --copy --force
> aclocal include
> autoheader
> automake --add-missing
> autoconf
> ./configure
> make
>
>
> Which process is simpler?
One command versus six commands is not much of an issue, when you have to
do it only once per project.
Besides, I'm not exactly sure whether this supposed framework comes even
close to offering the same flexibility as autoconf/automake.
We already know that you can't do VPATH builds or build-root installs here.
Yes, you can manually patch some installation files to achieve the same
thing, but this is exactly what you're complaining about here.
Furthermore, I see no way of, say, easily embed one package within another
one. The other day I wrote some code to run HMAC key digests using
arbitrary hash functions. I already had a completely separate, standalone
package that builds an MD5 hash library, and I had a second package doing
the same with the SHA1 hash function.
Without altering a single byte in the configuration script and the
makefile, both packages were simply added as a subpackage of the HMAC
library, and make dist in the top level now builds a single distribution
tarball, including the contents of both subdirectories containing the hash
functions.
I have a library that does RFC821 header parsing, and another library to do
RFC2045 MIME parsing on the message.
Both libraries are used in three separate projects, two of which are
publicly available. Unless you have both sets of source code, you would
not be aware that the subdirectories are really separate subprojects,
maintained completely separately. You'd assume that they were integrated
parts of the main project.
--
Sam
