From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Yet another bootstrap failure: Required feature `esh-groups' was not provided Date: Sun, 08 Jun 2008 07:17:23 +0900 Message-ID: <87zlpwrito.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080606155915.GA3953@muc.de> <20080606203541.GA1741@muc.de> <20080607095024.GC1812@muc.de> <20080607200821.GI1812@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1212876366 537 80.91.229.12 (7 Jun 2008 22:06:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Jun 2008 22:06:06 +0000 (UTC) Cc: rgm@gnu.org, Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 08 00:06:48 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 1K56Y2-0004Mg-Vi for ged-emacs-devel@m.gmane.org; Sun, 08 Jun 2008 00:06:07 +0200 Original-Received: from localhost ([127.0.0.1]:51179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K56XF-00017L-QH for ged-emacs-devel@m.gmane.org; Sat, 07 Jun 2008 18:05:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K56XA-00016E-EL for emacs-devel@gnu.org; Sat, 07 Jun 2008 18:05:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K56X8-00014j-SG for emacs-devel@gnu.org; Sat, 07 Jun 2008 18:05:12 -0400 Original-Received: from [199.232.76.173] (port=50587 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K56X8-00014a-Or for emacs-devel@gnu.org; Sat, 07 Jun 2008 18:05:10 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:36694) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K56Wv-0004ds-T7; Sat, 07 Jun 2008 18:04:58 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9B2421535AF; Sun, 8 Jun 2008 07:04:51 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 36B281A25C3; Sun, 8 Jun 2008 07:17:23 +0900 (JST) In-Reply-To: <20080607200821.GI1812@muc.de> X-Mailer: VM ?bug? under XEmacs 21.5.21 (x86_64-unknown-linux) 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:98637 Archived-At: Alan Mackenzie writes: alan> It can't be that difficult; lisp is designed for this type of alan> manipulation. It's not easy. Several people at XEmacs have tried over a period of years. What hasn't been tried yet is adapting the byte-compiler to the task. It's been suggested, but people who hack byte generally don't have a problem with debugging the makefile problem. alan> The dependencies absolutely must be generated automatically. alan> Whether this should be done by the byte-compiler or a separate alan> script isn't clear (yet). Such a separate script could alan> probably be run in temacs, creating the dependencies very early alan> in the build process. I don't think that makes a lot of sense. The problem is that to generate the Lisp dependencies you have to do this parsing of *all* the Lisp files. If you're going to do that, why not just do "find . -name '*.elc' -exec rm '{}'" and recompile? (Especially on Windows just reading that many files costs a lot of time, although the byte-optimizer is quite time-consuming, too.) Also, there's no real reason why (non-dependency-breaking) users and 3rd party developers should have to run this. Rather, have the committers run it as part of their precommit testing (although they mostly won't, at least you have an appropriate person to take out your frustration on). alan> One kind of "peer review" we could do is doing a build test as alan> part of the commission process. This might be a bit heavy on alan> server CPU time. That's not really helpful, it's only one machine. Eg, I misdoubt that Glenn sees very many broken builds, that's why he committed those changes. The useful aspect of "one-time" build testing is to insist that committers do a "make" just to ensure that anything they touched has no syntax errors in it, that's about the maximum effect you can ask for. "Build-bot" has been mentioned; that would be a much more useful infrastructure improvement. I suspect it would cost about as much hacker effort to set up a build-bot master as to hack the commit-hook to run a build, it needn't be redone when (medatashi, medetashi!) CVS bites the dust, and it won't involve repo downtime at all.