Re: Emacs vista build failures

[Thomas Lord <lord@emf.net>]

Just a quick note:

Johannes Weiner wrote:
> autoconf, automake, and so on.  Actually, I heard people referring to
> the whole generation of configure scripts and Makefiles as `autohell'.
>
> Yes, it's ovbiously a criticism.
>   

There are some very well known problems with that suite of tools,
for some users.    A few that come to mind:

1) Sometimes, after downloading this or that source package,
    perhaps making some changes, it is necessary simply to
    regenerate the configure script.   Yet, from time to time,
    the script can not be regenerated using the auto* suite already
    installed, the user must install alternate versions as well.
    A very frustrating experience occurs when building a program
    that requires, say, 3 separate libraries from various sources
    to be built first, each library using autoconf, ultimately requiring
    a total of four separate versions of autoconf to get the job done.
    This doesn't happen (in my experience) often, but often enough
    that it has left me with a bad feeling about the autoconf suite.

2) The autoconf suite has grown over the years and is now quite
    complicated both internally, and in use.   On the one hand, this
    reflects a needed accumulation of capabilities to be able to handle
    a very wide range of requirements from all the programs that use
    this suite.   On the other hand, it is "nervous making" to have 
something
    so fundamental to a project as its build process rely on such 
complicated
    tools that only a handful of people really understand well.

3) As Johannes mentioned, a special problem occurs if, in spite of its large
    number of features, a programmer needs to write a new macro or otherwise
    customize autoconf to do something new.   It can be very hard to 
pull together
    enough documentation and examples to be able to do this at all.   It 
is very
    hard to be confident, even when one gets something "working", that 
it works
    properly.

I think that those are *part* of the reason that in recent years more 
and more
people have written new configure/build systems, either general purpose or
targeted to a specific scripting language or other "closed universe" system.

Another reason (as far as I can tell) that scripting languages (and 
Java) often
use language-specific configure/build systems is because they want 
additional
functionality that deals with concepts not found in the autoconf suite.  
Most
commonly, configure/build/install is integrated with a *package system* by
which I mean a system for bundling and naming source in standard ways,
managing version numbering in standard ways, and creating "one step"
tools that find a desired package on the net, download it, recursively find
and download all prerequisite packages needed, then configure, build, and
install all of those.   The autoconf suite doesn't try to help with 
that.   It
is easier to build systems which do that for a single-language "closed 
universe",
and so several such systems exist.

Of course, finally, scripting languages often use their own
package / configure / build / install systems because writing such
a thing is a way to show-off the scripting language.   E.g.,
since you've already installed Ruby core, now here is a nice
package system written in Ruby (nevermind this /bin/sh, m4 stuff)
that is easy to use.

When I (as I said, probably in a few weeks after we move) put forward
straw-man recommendations, I do intend to implicitly address the problems
described above.   That is:  Yes, package management and prerequisite 
management
should be built-in to the GNU conventions;  other concepts such as 
validation
(checksum and signature checking) and auditing of trees on disk are also 
important;
conventions for handling multiple installed versions of packages cleanly 
are needed;
and, yes, the tools supporting these things do need to be simpler (yet 
without
sacrificing a short "bootstrapping path" to get them working -- the 
build tools
have to have relatively few dependencies on other packages).


-t