Subject: Re: cygwin's autoconf?
From: Soren A <[email-masked]>
To: [email-masked]
Date: Tue, 3 Dec 2002 01:48:02 +0000 (UTC)

Robert Collins <[email-masked]> wrote in
news:1038820917.2953.13.camel@lifelesswks: 

> On Mon, 2002-12-02 at 11:36, Soren A wrote:

>> At the very LEAST, something that does what AM_MAINTAINER_MODE
>> causes, should have been the *default* for all autotool'd packages,
>> and only by significant contortions should it have been made possible
>> to cause all that "default" behavior to get activated. But instead
>> it's the other way around, and users are at the mercy of package
>> maintainers' ignorance or awareness of the importance of (at the very
>> MINIMUM) placing AM_MAINTAINER_MODE in their configuration file. 

> Soren, please don't rant on the wrong list. Firstly, few people here
> are autotool gurus, and thus your erroneous statements may go
> uncorrected (see below for the correction). Secondly, this is a CYGWIN
> list, not a autotool design philosophy list.

I think I shall keep my own counsel WRT to what to post, and where ;-).

> AM_MAINTAINER_MODE is dangerous because it can easily lead to
> dependency problems when a user patches some autotool file, and then
> doesn't run the appropriate autotool to update. So, avoid
> AM_MAINTAINER_MODE whenever possible.

You are an Autotools guru, Robert. Based on my past surveys of the
Autoconf List archives, I have the impression that you may have
contributed more code to Autoconf & chums (?) than anyone else in
Cygwin. The trouble with Autotools is that more so than any software I
have ever encountered, it seems historically (at least up until now) to
*demand* that the *user* become a *guru* in order to use it reliably
(ESPECIALLY on Cygwin, which is why this disc. is not OT for this List).
So the distinction we might make in debate like this, between "users"
and "gurus", is a bit articifial or at least problematical and
debateable. 

Nonetheless I have to start by pointing out: what the HECK is a "user" 
doing patching some Autotool file?!?

This big issue affects everyone who uses packages which their creator has 
build-configured with GNU Autotools. That means base Cygwin itself here, 
and probably the majority of other official Cygwin packages maintained by 
the various package maintainers. It means that anyone who who wants for 
some reason (figuring out how to fix a bug they've encountered, just 
improving performance somehow, whatever) build from source is affected. So 
I AM going to use a little bandwidth to delve into some aspects.

The point about "users" is this: the theory WAS that a "user" (one who
builds the package from source code for installation to their own
system, but _that's all_) wouldn't even have to HAVE the intermediate
Autotools files for that package. Just the sources themselves (a given)
and a <configure> and a <Makefile.in> (and also maybe a <config.h.in>,
depending). As soon as you start talking about "users" needing to work
with intermediate (input) Autotools files (some are: <Makefile.am>,
<configure.in|ac>, <config_h.in|ac>), you are already talking about
somebody who isn't a "user" anymore. 

With the majority of the packages I have messed around with, that were
not already ported and part of Cygwin distros (and some that were), I
have had to leave the ranks of the "users" category and join the ranks
of the "hackers-of-build-conf" in order to succeed. I think that this
has been so common an experience for so many people that we forget that
the line between "user" and "hacker" ever existed, or why. I assert that
this is wrong and needs to be corrected. 

If the theory was that the "user" doesn't need to have the Autoconf files, 
then how does it look when the "user" runs ./configure and what gets output 
is a Makefile that requires *Autotools intermediate files* as prerequisites 
to build package targets?!? I'll tell you what it looks like: BROKEN-NESS. 
_It is broken_. If that isn't "broken" then your definition of "broken" and 
any common-sense one are very much at odds.

Before it looks like I am not addressing your point: if you are 
distributing a patch (say it is probably a unified diff format) that 
modifies Autotools files (and maybe a bunch of others), then I have to 
wonder why. OK, so your answer is that something in those Autotools build 
files is in need of correction. So that the build configuration for the 
package can be updated (fixed). So the category of persons who is 
*receiving* your patch is ... WHO? NOT "users", but "hackers". By 
definition. So by definition a "hacker[-on-the-build-config]" is someone 
who either has the *full competence and knowledgeability* to be hacking on 
the build configuration files, or they are not qualified to be in the 
"hacker" category. By definition.

This is the reality of the situation with Autotools. Builds based on them 
are so complex (and fragile, therefore the complexity fairly often gets 
exposed to the "user" category of persons) that half-way competence with 
Autotools is nearly worse than complete ignorance. Your theoretical user 
who runs a patch that updates Autotools files but doesn't pay attention to 
the fact that some Autotools invocation might need to be made (maybe 
because you, the package maintainer, haven't made enough effort to shove 
that aspect right in front of her face), then they have no business working 
with that software in that manner. This is the origin point of the wrong 
turn that Autotools have made: they are trying to make up for laziness, 
ignorance, lack of focus or time/effort investment on the part of hackers, 
to an unworkable degree. They are trying to be a "magic pill" for a problem 
for which no "magic pill" cure can exist.

I submit that because you are very invested in Autotools, Robert (which
was time-effort I know you put in with the best of intentions to just
contribute, and perhaps under protest at first, that is you'd have
rather been working on other things) ... but that because you are now so
close to it, you cannot see clearly the big picture as it shows itself
to the "user" category of persons. It seems likely that you were
offended by my previous posting -- again because you are invested in
Autotools. In fact I have to mention that I respect your substantial
contribution: I think it is in no small part because of you that
Autotools works even partly on Cygwin in a way that reflects how it
works on more orthodox platforms. So I hope you will accept my
expression of apology if I offended you. Nevertheless I think you've
reached an incorrect conclusion about the use of AM_MAINTAINER_MODE and
I certainly stand by my previous admonitions regarding it.

If the system of working out the development of a package won't stand up
to an insertion of AM_MAINTAINER_MDOE in the core piece of an Autobuild
setup, the <configure.ac> file, then what needs to get fixed is the
*system* (community, coordination), not a cheat / shortcut. I have some
suggestions about how to do it differently than it is often done, just
as you had 3 suggestions in your reply.

  1) First and foremost, I have come to the conclusion that the complete
removal of Autotools files from dists is necessary. The enormous amount
of bandwidth saved would alone make this attractive. The work generated
for the package developer would be partly (at least) offset by the
reduction in the need to answer questions from users not already
qualified to deal w/ the Autotools setup ("Hey, what's this Makefile.am,
how do I ..."), problem reports relating to missing dependencies, etc.
Make the Autotools files for a given package a SEPARATE DOWNLOAD archive
from the package sources. Make it clear (in List postings, READMEs on
ftp servers, and in WWW pages on HTTP servers) that the packages are
distributed *sans* Autotools build files. Only the end-user files
mentioned above would be part of the regular distro. The Autotools
"supplement" archive would have to be deliberately downloaded by a
hacker who knows that they need them and knows thoroughly what to do
with them.  

  2) I concur with your suggestion that Autotools files not be placed on 
CVS servers (in CVS repositories -- your list #3). Your logic there is 
good. I just think it needs to be taken further (my #1).

  3) Stop using the 'Automake' part of Autotools wherever possible. Update 
'Makefile.in's manually instead, or through some alternative system. If you 
still have to use Automake ... see below:

Again, you wrote:
> AM_MAINTAINER_MODE is dangerous because it can easily lead to
> dependency problems when a user patches some autotool file, and then
> doesn't run the appropriate autotool to update.

There is a huge twisted wormfarm of things "that can easily lead to..."
some kind of bad effect, when we are talking about Autotools. This one
is hardly singular or especially severe. 

IMO, preservation of the viability of the Makefile for the end-"user" is
the aspect that's gotten shortest thrift from everybody involved with
this. A Makefile that's got dependency on a file that originally only
the package author was supposed to need is a broken Makefile. A Makefile
that hides that dependency inside a nest of intertwined, indecipherable
recursive interdependencies (so that it is nearly impossible for a human
to simply read the Makefile and see what is wrong, to distinguish a case
of circularity from some other sort of accident, etc.) is a hideous
time-sucking abomination, not merely a broken Makefile.
AM_MAINTAINER_MODE simply exorcizes a *part* of that mess so that it
cannot bite the user. I advocate for the user -- I am a hacker and I
will take care of myself. As a hacker, I will study Autotools and learn
what is necessary to run when such-and-such a file has been edited or
patched. As a *user* or someone who can still remember what it is like to
be a user, I say that this situation isn't tolerable and people should
stop playing "Emperor's New Cloths" with it.

There really is something wrong. Despite all yours and everyone elses'
good work, sorry to have to say.

   Soren A

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/