From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: build broken: no defun org-float-time. Who's guilty, and what does he propose? Date: Tue, 8 Sep 2009 14:32:28 -0400 Message-ID: <11A3C60B-86D3-4DA8-9C68-46CBCF23DDB0@raeburn.org> References: <20090907092823.GA3210@muc.de> <83ws4a3b49.fsf@gnu.org> <0C7A6FC6-085D-4B7F-9DC0-FF0493876153@raeburn.org> <83tyze34fd.fsf@gnu.org> <88A44246-FB18-46DB-B92D-00E1716F5F68@raeburn.org> <83my562kda.fsf@gnu.org> <1825F3C9-40EA-402E-9FE9-6BF0A1207F6A@raeburn.org> <83k5092urt.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1252434788 12434 80.91.229.12 (8 Sep 2009 18:33:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2009 18:33:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 08 20:33:01 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 1Ml5Uu-00015S-Nu for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2009 20:32:57 +0200 Original-Received: from localhost ([127.0.0.1]:32978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml5Uu-0004BK-4T for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2009 14:32:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml5Un-00049k-5h for emacs-devel@gnu.org; Tue, 08 Sep 2009 14:32:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml5Ui-00045i-VA for emacs-devel@gnu.org; Tue, 08 Sep 2009 14:32:48 -0400 Original-Received: from [199.232.76.173] (port=60742 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml5Ui-00045e-KP for emacs-devel@gnu.org; Tue, 08 Sep 2009 14:32:44 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:57281 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml5UX-0007CY-IR; Tue, 08 Sep 2009 14:32:41 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n88IWTHR011803; Tue, 8 Sep 2009 14:32:29 -0400 (EDT) In-Reply-To: <83k5092urt.fsf@gnu.org> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:115147 Archived-At: On Sep 8, 2009, at 13:47, Eli Zaretskii wrote: >> From: Ken Raeburn >> Date: Tue, 8 Sep 2009 03:54:28 -0400 >> Cc: emacs-devel@gnu.org >> >> On Sep 7, 2009, at 23:20, Eli Zaretskii wrote: >>>> But if a minor comment change is made in the compiler source, >>>> must we >>>> recompile everything? >>> >>> Yes, why not? >> >> Excessive time spent rebuilding things that aren't going to change? > > This is why we want to avoid it as much as possible. What I asked is > why do you think we might be able to get away without it. Ah. Well, in the abstract, if it really is just a comment change (or whitespace change, or minor coding change that the optimizer boils down to the same byte code as the previous version), it won't affect the operation of the compiler and thus won't affect the result. Concretely, there are ways we can check for that -- see if the "real" content of the .elc file for the compiler source has changed, by which I mean stuff other than the compilation info at the front. We could compare most of the file content with the previous version, or get rid of those comments and compare entire files, and retain the old file versions and old timestamps on unchanged files for further dependency checks, if we keep relying on make to do the grunt work. I think GCC's build system has some mechanisms for doing that sort of thing, though it's a bit awkward. Bypassing make, or at least its timestamp checking as the primary mechanism, we could compute and record md5 (or sha1, or sha2) sums of the important parts of the files, and compare them to see if things have changed in any way we care about. (E.g., foobar.elc could include in its compilation-info comments, "foobar.el:47ecb138... subr.elc:3feb9814... quux.elc:4857fabd...". For performance, it could even cache its own md5 sum so we don't have to keep recomputing it.) The recompilation command could check the dependencies against the recorded sums, and if they all match, just update the timestamp on the output file, to keep make from re-invoking that compilation command. Touching subr.el could still cause a cascade of recompilation commands, but they'd just be updating timestamps. Ken