Re: MinGW GLib

[Soren A]

[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 <address@hidden> wrote in 
news:address@hidden:

> 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