From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: build broken: no defun org-float-time. Who's guilty, and what does he propose? Date: Mon, 7 Sep 2009 13:35:56 +0000 Message-ID: <20090907133556.GB3210@muc.de> References: <20090907092823.GA3210@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1252330379 28590 80.91.229.12 (7 Sep 2009 13:32:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Sep 2009 13:32:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 07 15:32:52 2009 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 1MkeKx-0000ZH-Uw for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2009 15:32:52 +0200 Original-Received: from localhost ([127.0.0.1]:51484 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MkeKw-0002A8-RU for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2009 09:32:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MkeKq-00026R-Mv for emacs-devel@gnu.org; Mon, 07 Sep 2009 09:32:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MkeKm-000207-9W for emacs-devel@gnu.org; Mon, 07 Sep 2009 09:32:44 -0400 Original-Received: from [199.232.76.173] (port=41533 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MkeKl-0001zq-Vu for emacs-devel@gnu.org; Mon, 07 Sep 2009 09:32:40 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:3455 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MkeKl-0005xB-CW for emacs-devel@gnu.org; Mon, 07 Sep 2009 09:32:39 -0400 Original-Received: (qmail 37432 invoked by uid 3782); 7 Sep 2009 13:32:36 -0000 Original-Received: from acm.muc.de (pD9E50036.dip.t-dialin.net [217.229.0.54]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 07 Sep 2009 15:32:35 +0200 Original-Received: (qmail 7097 invoked by uid 1000); 7 Sep 2009 13:35:56 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:115084 Archived-At: Hi, Miles, On Mon, Sep 07, 2009 at 07:05:32PM +0900, Miles Bader wrote: > Alan Mackenzie writes: > > This is a serious process bug we have, we've had for years, and we > > MUST fix. If it's not fixed soon, I'm just going to give up on Emacs > > maintenance and bid the project goodbye. The pain level is too high. > I agree that this sort of thing can be annoying, but the procedure for > dealing with such things is well known and not particular onerous: > "make bootstrap" (could be a bit onerous if you've got a very slow > machine though) Maybe I'm not as much of a real man as you are. I find the process onerous indeed. The build fails, you've got to read error messages, possibly grep the source code for a missing symbol, have a quick check of ChangeLog (MOST of us put details of changes there), ... And yes, make bootstrap takes a long time, where a long time is perhaps 20 minutes or half an hour. Very slow PCs haven't been sold since the 1990s, so there probably aren't too many of them being used by Emacsers. The point is, make should work. Not best out of ten, not all but a "few times a year", but always, modulo the occasional real screwup. > Moreover, it happens very rarely -- I'd guess only a few times a year, No, it happens frequently -- I'd guess several times a year. > and far less often than the more usual sort of problem where somebody > just committed a bogus change that simply doesn't compile (though that > kind of problem is fairly rare too). Er, excuse me, but that comes into the category of build failure too. There's no justice in committing build-breaking changes, it's anything but just. It's a window in the donkey for everybody. That our process allows it is a bug. We earnestly discussed fixes about a year ago. > I don't know how you get "the pain level is too high" out of that... Because I've been sensitised to it by the repeated instances of it over the last few years. It happened to me this morning, only the second or third time I've cvs updated since the release of 23.1. Because it completely throws my train of thought, destroying my morning's work. Above all, because it forces me to do dumb, brainless, moronic stuff which a computer program, for example a build script, could do far faster, painlessly, with less effort than me. Having forced myself to look at it, it's fairly obvious. The build process is loading the wrong file in response to (require 'org-exp). It's loading an out of date file, because our makefiles are broken. That's not news to anybody. And make bootstrap is a ridiculous overreaction to one out of date file.elc. Maybe the solution is, somehow, to load the more up to date of foo.el and foo.elc during the build process. In fact, the build process even admits it knows that "source file foo.el newrt than byte-compiled file". There's probably a terribly good reason why it doesn't fix the problem rather than just reporting it. > -Miles -- Alan Mackenzie (Nuremberg, Germany).