Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com X-Injected-Via-Gmane: http://gmane.org/ Path: not-for-mail From: Soren A Subject: Re: cygwin's autoconf? Date: Tue, 3 Dec 2002 01:48:02 +0000 (UTC) Organization: Sporadically, Occasionally Lines: 174 Message-ID: References: <3DE8CDE5 DOT 8060307 AT lapo DOT it> <012101c2987f$67c9eb70$78d96f83 AT pomello> <3DE8E77D DOT 3000603 AT lapo DOT it> <3DE9114C DOT 1070309 AT ece DOT gatech DOT edu> <3DE9E769 DOT 7010104 AT lapo DOT it> <3DEA4653 DOT 10401 AT ece DOT gatech DOT edu> <1038820917 DOT 2953 DOT 13 DOT camel AT lifelesswks> NNTP-Posting-Host: 123.syracuse-05-10rs.ny.dial-access.att.net X-Trace: main.gmane.org 1038880082 3734 12.89.4.123 (3 Dec 2002 01:48:02 GMT) X-Complaints-To: usenet AT main DOT gmane DOT org NNTP-Posting-Date: Tue, 3 Dec 2002 01:48:02 +0000 (UTC) User-Agent: Xnews/5.04.25 X-Archive: encrypt Robert Collins wrote in news:1038820917 DOT 2953 DOT 13 DOT camel AT 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 and a (and also maybe a , depending). As soon as you start talking about "users" needing to work with intermediate (input) Autotools files (some are: , , ), 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 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/