From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Emacs vista build failures Date: Mon, 21 Jul 2008 09:48:24 -0700 Message-ID: <4884BDD8.6030306@emf.net> References: <36366a980807101702r5677d096g8e62ef5b3e278868@mail.gmail.com> <4eb0089f0807111217m66d6cf4el777c197c107ce034@mail.gmail.com> <87skug6tq5.fsf@catnip.gol.com> <4eb0089f0807111345h13eccdds9b2cf43370b94074@mail.gmail.com> <4eb0089f0807121340x5e26f6dbve03ef50b238f3a3a@mail.gmail.com> <87k5fph5rh.fsf@stupidchicken.com> <20080713214648.GB1076@muc.de> <20080714195651.GF3445@muc.de> <487C5FA3.4070603@emf.net> <87zloggji9.fsf@catnip.gol.com> <878wvxxkn6.fsf@catnip.gol.com> <87ej5oz4pb.fsf@saeurebad.de> <87vdyzxype.fsf@saeurebad.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1216656021 5457 80.91.229.12 (21 Jul 2008 16:00:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Jul 2008 16:00:21 +0000 (UTC) Cc: miles@gnu.org, acm@muc.de, emacs-devel@gnu.org, rms@gnu.org, drobinow@gmail.com To: Johannes Weiner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 21 18:01:08 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KKxop-0004DK-2G for ged-emacs-devel@m.gmane.org; Mon, 21 Jul 2008 18:00:59 +0200 Original-Received: from localhost ([127.0.0.1]:45130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KKxnw-0006CY-3W for ged-emacs-devel@m.gmane.org; Mon, 21 Jul 2008 12:00:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KKxnq-0006By-An for emacs-devel@gnu.org; Mon, 21 Jul 2008 11:59:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KKxno-0006BM-I3 for emacs-devel@gnu.org; Mon, 21 Jul 2008 11:59:57 -0400 Original-Received: from [199.232.76.173] (port=34969 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KKxno-0006BJ-Dg for emacs-devel@gnu.org; Mon, 21 Jul 2008 11:59:56 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:55545) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KKxnd-0006DJ-9r; Mon, 21 Jul 2008 11:59:45 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.114.9] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 35372531; Mon, 21 Jul 2008 08:59:40 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <87vdyzxype.fsf@saeurebad.de> X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:101088 Archived-At: Just a quick note: Johannes Weiner wrote: > autoconf, automake, and so on. Actually, I heard people referring to > the whole generation of configure scripts and Makefiles as `autohell'. > > Yes, it's ovbiously a criticism. > There are some very well known problems with that suite of tools, for some users. A few that come to mind: 1) Sometimes, after downloading this or that source package, perhaps making some changes, it is necessary simply to regenerate the configure script. Yet, from time to time, the script can not be regenerated using the auto* suite already installed, the user must install alternate versions as well. A very frustrating experience occurs when building a program that requires, say, 3 separate libraries from various sources to be built first, each library using autoconf, ultimately requiring a total of four separate versions of autoconf to get the job done. This doesn't happen (in my experience) often, but often enough that it has left me with a bad feeling about the autoconf suite. 2) The autoconf suite has grown over the years and is now quite complicated both internally, and in use. On the one hand, this reflects a needed accumulation of capabilities to be able to handle a very wide range of requirements from all the programs that use this suite. On the other hand, it is "nervous making" to have something so fundamental to a project as its build process rely on such complicated tools that only a handful of people really understand well. 3) As Johannes mentioned, a special problem occurs if, in spite of its large number of features, a programmer needs to write a new macro or otherwise customize autoconf to do something new. It can be very hard to pull together enough documentation and examples to be able to do this at all. It is very hard to be confident, even when one gets something "working", that it works properly. I think that those are *part* of the reason that in recent years more and more people have written new configure/build systems, either general purpose or targeted to a specific scripting language or other "closed universe" system. Another reason (as far as I can tell) that scripting languages (and Java) often use language-specific configure/build systems is because they want additional functionality that deals with concepts not found in the autoconf suite. Most commonly, configure/build/install is integrated with a *package system* by which I mean a system for bundling and naming source in standard ways, managing version numbering in standard ways, and creating "one step" tools that find a desired package on the net, download it, recursively find and download all prerequisite packages needed, then configure, build, and install all of those. The autoconf suite doesn't try to help with that. It is easier to build systems which do that for a single-language "closed universe", and so several such systems exist. Of course, finally, scripting languages often use their own package / configure / build / install systems because writing such a thing is a way to show-off the scripting language. E.g., since you've already installed Ruby core, now here is a nice package system written in Ruby (nevermind this /bin/sh, m4 stuff) that is easy to use. When I (as I said, probably in a few weeks after we move) put forward straw-man recommendations, I do intend to implicitly address the problems described above. That is: Yes, package management and prerequisite management should be built-in to the GNU conventions; other concepts such as validation (checksum and signature checking) and auditing of trees on disk are also important; conventions for handling multiple installed versions of packages cleanly are needed; and, yes, the tools supporting these things do need to be simpler (yet without sacrificing a short "bootstrapping path" to get them working -- the build tools have to have relatively few dependencies on other packages). -t