[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build broken: no defun org-float-time. Who's guilty, and what does

From: Ken Raeburn
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

On Sep 8, 2009, at 13:47, Eli Zaretskii wrote:
From: Ken Raeburn <address@hidden>
Date: Tue, 8 Sep 2009 03:54:28 -0400
Cc: address@hidden

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]