Re: MinGW GLib

[Soren A]

Hello, Tom, All,

First off my reply this time will be pretty lacking in detail (if not in
general verbiage). I am temporarily getting weary of the heat I am
taking for the length of postings (no advice or comment is being
solicited by mentioning this; please be adviced that I probably won't
pay any attention to it if you do offer it anyway) and it is just a
question of my available time. 

In this posting you are offering a rebuttle (and did a fine job, notably 
lacking in emotionalism) of my criticisms of Automake, which is fine and is 
your right. First of all though I need to note that my artcle was not at 
its inception intended to be a thorough and comprehensive critique of 
Automake. It was actually many layers of replies deep into a rather long 
thread that started in a very different place. And primarily it was about 
refuting the words placed in my mouth to the effect that I was 
characterizing *all* use of *all* the Autotools as misguided and damaging.

To discuss a software component as complex as Automake and do a *good* job 
of doing so, one really has to take the time and *get it right*. I cannot 
do justice to the discussion when I am pressed for time and cannot devote 
several hours to preparatory research. Without doing so I cannot feel that 
I have offered a piece that adequately guards against misunderstandings to 
my standards of effort.

Tom Tromey <address@hidden> wrote in 
news:address@hidden:

>>>>>> "Soren" == Soren A <address@hidden> writes:
> 
> Soren> IOW, the way Automake is designed is to make keeping a very
> Soren> complex package's dependencies tracked so that it can be
> Soren> smarter than the developer -- so that if the developer (package
> Soren> author / maintainer) forgets to update something by running the
> Soren> appropriate Autotool command, the Makefile will cause it to
> Soren> happen for him/her. This means nests inside nests inside nests
> Soren> of recursive interdependency, a hideous logical mess to try to
> Soren> mentally untangle and the primary thing that makes standard
> Soren> Automake-generated Makefiles unreadable by humans.
> 
> First, the maintainer can disable these update features.  Many
> maintainers do.

This is an instance of where examples are needed. The only mechanism I know 
of -- well I know of two now, recently -- for doing this is to write a 
'configure.ac' file that contains the automake macro invocation 
"AM_MAINTAINER_MODE". The second thing pertaining to this is the flag 
`automake -i' which I think is explained in brief as "disabling automated 
dependency tracking".

> Second, this part of the generated Makefile is pretty small.  I
> disagree that this part is really that hideous, or unreadable.  Other
> parts are less readable, for instance the way automake generates lots
> of intermediate targets which have no purpose but to simplify
> automake's implementation (or perhaps simplify some old
> implementation, and which now are truly useless).

That is the part that I meant. I may have written in such a way as to lead 
to misunderstanding. I was talking about this: the intermediate targets 
that are there just for Automake's internal use. I had thought that my 
expressions like "recursive interdependencies" would adequately indicate 
what I meant, but perhaps that did not.

> Soren> IMHO this is an error of Greek-Epic proportions on the part of
> Soren> the Automake author, a deranged distortion of the Virtue of
> Soren> Hubris
> 
> Automake Rex.

LOL. Good one.

> Soren> A system that tries to relieve the developer to THAT degree, of
> Soren> ordinary vigilance and concentration on his/her task, is IMO a
> Soren> major mistake and something to be regarded with deep healthy
> Soren> skepticism.
> 
> It would help if you could be specific.  Sometimes I've erred in
> making errors of things that perhaps should go unnoticed.  But the
> situation isn't nearly as clear and simple as you try to make it.  For
> one thing, giving fewer errors means more developer time spent reading
> automake's output.

I am really NOT trying to make any part of the situation seem clear and
simple -- and the more I try to be _non-reductionist_ the more heat I
take for making my postings too long and wordy. 

Here's where I 'fess up: It doesn't impact all developers equally and your 
decisions may suit developers on the majority of platforms (anything 
GNU/Linux -like i expect) very well. It doesn't serve or suit developers on 
the problematic platforms that I work with well at all. I am a Windows 
user; Cygwin and MinGW are my environment. On these problematic platforms 
the fundamental design decisions of Automake and other Autotools work 
against me a lot. What i have often had to do is come up with a kludge but 
cannot even do that until I can get some insight into "what's breaking" 
inside Autotools. Too often I cannot get that easily because Automake is 
designed to just make something die.


> Soren> Nothing about the GNU documentation for Autotools claims that
> Soren> you *have to* use Automake at all. In principle it is perfectly
> Soren> possible to use Autoconf, and even Libtool, without using
> Soren> Automake.
> 
> Not only in principle.  Many packages exist which do this.  Emacs.
> gcc.  gdb.  binutils.  Etc.
> 
> Soren> Attention is relative and comes as cumulative impact of many
> Soren> instances of complaints as well as response to single-authored
> Soren> instances of cogent critique.
> 
> ...which this isn't.  Cogency implies persuasiveness.

See top of posting. Agreed. This wasn't as cogent as it needs to be, as is 
demanded by the subject we are into now, which at inception of this thread 
was a totally different thing. I haven't probably, from your POV and many 
others, given you enough to work with to "fix" Automake to my satisfaction 
(if such could even be done). However I have seen very few articles posted 
in the past, either, that are detailed and cogent enough to embody the kind 
of data that is required here. I have held off posting my 'critique' of 
Automake to a GNU Autotools List for many, many months and finally decided 
that with this thread, I was going to do so, or it probably would never get 
done. "Ready or not... ". If I've bungled it so that nothing good can come 
of it (besides my venting, which I needed to do), then so be it.

> {...} well, merely irritating.  Or, to put it another way, there's
> nothing in your message that either induces me, or even provides me
> enough information, to make any specific modification to automake. 
> (Though I will immediately start removing all the hideousness, not to
> mention the various influences of Agamemnon.)

Hopefully (I think apparently) you possess enough wisdom not to take the
venting I needed to do, too personally. You have to understand that I am
experiencing Automake as this "entity" that looks like a bundle of
Badness to me subjectively, just doesn't do what I want or what I mean.
And my other, main point, which is getting lost, is that I have a major
beef with with _package maintainers_ (as opposed to with you) who don't
get it that the package build configuration they have created isn't
*going far enough* because they've decided that learning about the
Automake (and generally Autotools) options and configurations and
upgrade details isn't required of them -- that they are too busy or the
subject is too onerous or the need just isn't pressing enough. As a
result they are shunting the trouble onto at least a subset of their
potential users who then have to learn Autotools in order to fix their
fragile, brittle, and/or outdated package configuration! And when
approached about this (which even to do so is additional time and effort
invested by a user, that THEY could be putitng into other things --like
choosing another competing software package or even writing their own
from scratch!) too many will just respond negatively, saying "I don't
care" or "it's you who are doing things wrong" or "don't bother me, go
complain to the Autotools people".  

Bottom line of the point of the above paragraph: the user base of
Automake (and Autotools generally) *isn't sufficiently knowledgeable*
about the build system they are employing and there is something that
could be done about that: go in and purge the sites and documentation of
ANY suggestion that creating an acceptably robust build configuration
using Autotools ought to be *easy* and *almost effortless* and instead
_be honest_ and _strict_ with the user (package developer / maintainer)
and *admit* that many, many of *their* users are complaining! Tell them
that it is *NOT* necessarily easy to use Autotools to create a robust
build setup using Autotools; tell them to expect it to be a lot of work.
Take the risk of scaring people off. Take more responsibility for the
problems we, the users of their packages, are having; be courageous. 

Even doing what I am suggesting above is only retroactive action and
won't fix the many packages out there that are in bad shape. But it is a
start and it will at least put new Autotools users on a better path,
maybe preventing careless use in a few more cases and that will slowly
lead to better package build configs being out there in the future. 

One thing I might suggest that would contribute to this increased
emphasis on user education ("user" being in this sense not ME, but the
bloke who maintains the package I am struggling to build) would be to
start a list of real packages which are known to have done the Autotools
thing exceptionally well. I came across one recently ... what was it ...
I think it might have been 'wget' but am not sure. What I mean is that,
with nods to the existing Autotools Tutorial and especially AutoBook, it
STILL doesn't seem to be "enough". (I know this must be frustrating for
you to hear but I can only give you my honest impression of the nature
of the deficiency). The more examples of real-world working code people
can be told to look at, the better. Maybe even start a quarterly award
program to give special recognition to packages which are authored with
exceptionally robust and well-thought-out Autotools-based build
configurations. 

>>> 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.

> For all we know one of the automake maintainers is already working on
> one.
> 
>:-)

That would be great. ITMT we have a (to use a pure physics analogy)
major momentum situation to recognize here. Putting my thinking cap on
and doing my best cogitating, I cannot with intellectual honesty say
that I foresee such a solution, even if it should be unveiled tomorrow,
solving the existing problem of so many packages being out there (some
naturally slipping into nearly-unmaintained status as time goes by) with
creaky old Autotools setups. 

  Best regards,
    Soren A


-- 
What do Internet Mailing Lists and crowded neighborhoods have in
common? Both will either drive you out or teach you how to ignore
barking dogs.