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

[Ken Raeburn <raeburn@raeburn.org>]

On Sep 8, 2009, at 13:47, Eli Zaretskii wrote:
>> From: Ken Raeburn <raeburn@raeburn.org>
>> 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