From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Yet another bootstrap failure: Required feature `esh-groups' was not provided Date: Fri, 06 Jun 2008 23:41:36 +0300 Message-ID: References: <20080606155915.GA3953@muc.de> <20080606203541.GA1741@muc.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1212785015 32030 80.91.229.12 (6 Jun 2008 20:43:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Jun 2008 20:43:35 +0000 (UTC) Cc: rgm@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 06 22:44:17 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 1K4in9-0000aT-B5 for ged-emacs-devel@m.gmane.org; Fri, 06 Jun 2008 22:44:07 +0200 Original-Received: from localhost ([127.0.0.1]:60099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K4imM-00088s-FU for ged-emacs-devel@m.gmane.org; Fri, 06 Jun 2008 16:43:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K4imI-00088P-2N for emacs-devel@gnu.org; Fri, 06 Jun 2008 16:43:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K4imG-00087c-N6 for emacs-devel@gnu.org; Fri, 06 Jun 2008 16:43:13 -0400 Original-Received: from [199.232.76.173] (port=59433 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K4imG-00087Z-Iq for emacs-devel@gnu.org; Fri, 06 Jun 2008 16:43:12 -0400 Original-Received: from mtaout7.012.net.il ([84.95.2.19]:57650) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K4imC-0001kL-8b; Fri, 06 Jun 2008 16:43:08 -0400 Original-Received: from HOME-C4E4A596F7 ([80.230.28.131]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K220052661IUZJ0@i-mtaout7.012.net.il>; Fri, 06 Jun 2008 23:24:54 +0300 (IDT) In-reply-to: <20080606203541.GA1741@muc.de> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 10 (1203?) 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:98542 Archived-At: > Date: Fri, 6 Jun 2008 20:35:41 +0000 > From: Alan Mackenzie > Cc: emacs-devel@gnu.org > > Our makefile system is broken. The whole point of the make utility is to > build software automatically, so that hackers don't need to waste their > time messing with arcane minutiae. Is it really to much to expect to be > able to type > > % ./configure ; make some-target > > and have the software build (modulo errors in the files.{c,el}? This does work, just not in an arbitrary CVS-updated sandbox. That is, in a release tarball, the configury behaves exactly as you want it to. > Forgive my sarcasm, but am I supposed to read through (or diff) the > entire Emacs process documentation every time I update Emacs, just in > case some crazed lunatic, er sorry, I mean some conscientious hacker, has > "enhanced" it? Sorry, Alan, but your expectations are too high. AFAIK, a bootstrap build is guaranteed to work only in a fresh CVS checkout. It is not guaranteed to work in a sandbox littered by stale files. I agree that it would be great to have more, but it's a lot of work, and the results cannot be reasonably tested in practice, since the number of different ways you can screw up your sandbox is infinite. People who regularly update from CVS trunk are expected to be able to tinker with their files, and have enough energy for that. > Just as a matter of interest, in the last few months on emacs-devel > there have been approximately these numbers of threads complaining about > Emacs CVS not building: > > May: 7 > April: 9 > March: 9 > February: 2 That's expected, in a trunk that is actively developed by many contributors at once. > Whatever the reason, this is a horrendous time sink. Failure to build > the CVS head should essentially _never_ happen - possibly once or twice > a year at most. Sorry, but it's hopelessly unrealistic to request that. Given the number of different platforms we support, it is impractical even to request that any given change will compile on all of them, let alone build without a hitch. > Recently, I proposed installing a tool on savannah which would trigger a > test build every time source files were committed. The proposal didn't > meet with much enthusiasm. Well, how about volunteering to do it, then? It obviously bugs you enough to make you a motivated individual.