[Top][All Lists]
[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
- Re: Emacs vista build failures, (continued)
- Re: Emacs vista build failures, Barry Fishman, 2008/07/27
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/28
- Re: Emacs vista build failures, Barry Fishman, 2008/07/28
- Re: Emacs vista build failures, tomas, 2008/07/29
- Re: Emacs vista build failures, Barry Fishman, 2008/07/29
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/29
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/29
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/29
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/25
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/22
- Re: Emacs vista build failures,
Thomas Lord <=
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/21
- Re: Emacs vista build failures, Miles Bader, 2008/07/21
- Re: Emacs vista build failures, Lennart Borgman (gmail), 2008/07/20
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/20
- Re: Emacs vista build failures, David Kastrup, 2008/07/21
- Re: Emacs vista build failures, Lennart Borgman (gmail), 2008/07/21
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/21
- Re: Emacs vista build failures, Stephen J. Turnbull, 2008/07/20
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/20
- Re: Emacs vista build failures, Richard M Stallman, 2008/07/20