emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs vista build failures


From: Thomas Lord
Subject: Re: Emacs vista build failures
Date: Mon, 21 Jul 2008 09:48:24 -0700
User-agent: Thunderbird 1.5.0.5 (X11/20060808)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]