[I've tried to set the 'follow-up' field to only the Autoconf List since I think with this my reply to Tor, the specific relevence to the MinGW User's List will have been about used up; but Gmane / my newsreader wouldn't allow it. Sorry.]
Tor Lillqvist <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > Ouch. This is even stronger than JMD's postings. > > I'll refrain from feeding a flame war, and comment on just one point: > > Soren A writes: > > In case it isn't clear yet, I am not going to budge on my views > > about how bad automake is. > > (and presumably also autoconf, autoheader and libtool?) Incorrect presumption. Earlier today someone asked me privately: > Would you really refuse to use some software because it used > automake? Yes, definitely. If I could detect in advance that the author had hacked together a careless set of build configuration files and particularly had not updated or checked them in a while, especially. > And, since you dislike automake so much, what do you prefer to use > instead? This deserves a longer answer, but basically I will mention that I have been playing around with a GNU package named "mfg" (you can find it at the GNU Software Directory page). "mfg" has been around for years and it is a template-based "makefile generator". Rhetorical Argument: "I have has only just started learning automake, but haven't run into anything horrifying yet." Answer: What's horrifying is what happens when the Makefile generated by using Automake upstream (by running 'configure', of course) decides that something in the build configuration is a prerequisite to itself (the Makefile) as a target-prerequisite of the source files you actually want to build. IOW, the way Automake is designed is to make keeping a very complex package's dependencies tracked so that it can be smarter than the developer -- so that if the developer (package author / maintainer) forgets to update something by running the appropriate Autotool command, the Makefile will cause it to happen for him/her. This means nests inside nests inside nests of recursive interdependency, a hideous logical mess to try to mentally untangle and the primary thing that makes standard Automake-generated Makefiles unreadable by humans. It also means the whole thing is unacceptably brittle. And when a human-authored Makefile isn't doing what you need, you go in and edit it. When an Automake-generated makefile goes wrong, it does so like a Hannibal Lecter of wrongness. Very, very hard to fix and it can feel like it leaves a trail of semi-devoured corpses behind it. As a basic principle Automake has taught me to be very wary of software that tries to be much smarter than *I* myself, the developer, am. IMHO this is an error of Greek-Epic proportions on the part of the Automake author, a deranged distortion of the Virtue of Hubris (I am assuming that readers are sufficiently acquainted with Perl to know the reference). A system that tries to relieve the developer to THAT degree, of ordinary vigilance and concentration on his/her task, is IMO a major mistake and something to be regarded with deep healthy skepticism. Nothing about the GNU documentation for Autotools claims that you *have to* use Automake at all. In principle it is perfectly possible to use Autoconf, and even Libtool, without using Automake. > So, what are you going to do about it? To put it bluntly, hasn't it > always been like this in the Open Source world: there are lots of > people who complain (and often rightly) when something is broken (by > design, perhaps). But, it's those who show working code that get the > attention and peer recognition. Attention is relative and comes as cumulative impact of many instances of complaints as well as response to single-authored instances of cogent critique. Whether that is good or not (because I happen to think that such a thing as "mob rule" is a real phenomenon in human affairs and can be extremely destructive) is another question. Anyway, I can only do my best on any given occasion to present cogent arguments expressing my viewpoint. > I am certain that if somebody would create an elegant, working, > unified cross-platform replacement for auto*+libtool+make, written in > *one* language of choice (preferrably some Lisp variant, or Perl, > instead of the current mixture of C, /bin/sh, m4, and Perl), many > software writers would embrace it. There are a *lot* of build-configuration systems already out there and I have investigated some of them (it wouldn't be fair to say "all of them" because it is very likely that I haven't found some or many yet). It isn't that people haven't been thinking about this. But nothing that I have looked at thus far seems truly ambitious enough to challenge Autotools -- none so far seems to address the true "problem domain" in its true magnitude. To sum my short answer to the thrust of your questions (and the most important aspect of the answer is, "what I am going to try to put more work into, so that I can *demonstrate some solutions*" to others rather than merely posting tirades): my current thinking is that a GNU-based build system is fine ||AND|| you can provide one ||WITHOUT|| employing Automake for many, many different types of packages, large and small. And I would be neglectful if I didn't add that GNU 'make' is one of the neatest tools ever devised, and learning how to author good GNUmakefiles can go a long way towards providing whatever support the package author thinks s/he needs to get the software built right. IMO requiring people who want to build your package to use GNU 'make' to do so is *not* unreasnable considering how freely-available and widely-ported 'gmake' is. Regards, Soren A
