From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.devel Subject: Re: AARRRRGGH! Die Libtool, die! Date: Sat, 15 Feb 2003 16:56:12 -0800 (PST) Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <200302160056.QAA15802@morrowfield.regexps.com> References: <200302151436.h1FEacTL013547@smtpzilla1.xs4all.nl> <15950.54058.520676.489870@blauw.xs4all.nl> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1045356356 23587 80.91.224.249 (16 Feb 2003 00:45:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 16 Feb 2003 00:45:56 +0000 (UTC) Cc: rlb@defaultvalue.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18kCwM-00068I-00 for ; Sun, 16 Feb 2003 01:45:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18kCxy-000362-02 for guile-devel@m.gmane.org; Sat, 15 Feb 2003 19:47:34 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18kCwy-00021a-00 for guile-devel@gnu.org; Sat, 15 Feb 2003 19:46:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18kCwR-0000jN-00 for guile-devel@gnu.org; Sat, 15 Feb 2003 19:46:00 -0500 Original-Received: from 1cust196.tnt13.sfo8.da.uu.net ([63.10.241.196] helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18kCwK-0000Wh-00 for guile-devel@gnu.org; Sat, 15 Feb 2003 19:45:53 -0500 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id QAA15802; Sat, 15 Feb 2003 16:56:12 -0800 (PST) (envelope-from lord@morrowfield.regexps.com) Original-To: hanwen@cs.uu.nl In-reply-to: <15950.54058.520676.489870@blauw.xs4all.nl> (message from Han-Wen Nienhuys on Sun, 16 Feb 2003 00:54:18 +0100) Original-cc: guile-devel@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1942 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1942 > (Personally, I'd rather have all those tools (auto* included) > written in something like perl -- it's nearly as ubiquitous > and *far* more managable. Of course perl couldn't use them > then, but AFAIK, it doesn't anyway.) I would use Python myself, but otherwise I concur. Bah. Both perl and python are not stable. `sh' hasn't changed much in a decade and probably won't for another decade if ever. `sh' is more than adequate for the job. If you must reach for something more, especially on this list, for gosh sakes, pick something rooted in stable standards: reach for SCSH, you traitors. The problems with the auto* family of tools include: 1) reliance on separate distribution Everything depends on those tools, and those tools aren't stable. Build systems are an area where you want conventions, not dependencies. It sucks that developers have to keep multiple versions of these tools around. 2) wrong approach to application portability The portability problem these days is much smaller than it was when autoconf was conceived. Feature tests are an inelegant solution that has, for the most part, failed (just try building a randomly selected set of public projects on anything other than a recent GNU/Linux system). A better use of everyone's time would be to work on designing and stabilizing a portability library against which new applications could be built and to which old applications can be ported. 3) wrong approach to /bin/sh portability (m4) The `/bin/sh' portability problem is much smaller today than it was when autoconf was conceived. The role of m4 (GNU m4 specifically, no less) in autoconf has outlived its usefulness. The obfuscation cost of the use of m4 in autoconf now outweighs its payoff. 4) wrong approach to makefile portability The `make' portability problem is much smaller today than it was when autoconf was conceived. The auto* family clings to requirement of makefile portability even while GNU make runs pretty much everywhere. 5) wrong approach to makefile automation Roughly speaking, `automake' bridges the gap between historic versions of `make' and the capabilities of GNU make. If you commit to GNU make, you simply do not need automake. 6) lack of consideration for package management The functionality of package managers belongs in the configure/build tools. 7) excessive complexity I've scientifically measured it and the result is official: the auto* family is a gazillion times more complicated than it needs to be. Of course, the battle-scarred maintainers of these packages will regale with you with horror stories about how each and every detail of the auto* family came into being -- but they'll also falsely ask you to believe that those stories justify making each and every free software project dependent on solutions to 20 year old problems that no longer exist. etc. Oh yeah -- did I mention that my `package-framework' contains the skeleton of a replacement for the auto* family? I guess I must be biased.... -t _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel