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 <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: >>>>>> "Soren" == Soren A <[EMAIL PROTECTED]> 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.
