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

[Ken Raeburn <raeburn@raeburn.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?

>> We don't generally make .o files explicitly depend on the C
>> compiler.
>
> If a compiler can change the ABI, you must.

True.  Is that something we need to worry about with Emacs?  It's  
changed a handful of times in the history of Emacs, but hasn't it  
generally been backwards-compatible?  Don't older .elc files generally  
still work?  Do we really need to force a recompile and *make*  
everything take advantage of the latest and greatest optimizer tweaks  
or whatever?

>>> Btw, I don't understand what problem do you see with files preloaded
>>> by loadup.  They should simply be all prerequisites of temacs, and
>>> that's it, right?
>>
>> Well, "emacs", not "temacs" which is just linked from the C code, but
>> also I was assuming we wouldn't make the emacs binary an explicit
>> dependency for the .elc files
>
> Not all of them, just those that are preloaded.  We already have that
> dependency:
>
>  emacs${EXEEXT}: temacs${EXEEXT} ${etc}DOC ${lisp} $ 
> {SOME_MACHINE_LISP}

So "emacs" gets rebuilt if subr.el(c) is updated, yes.  But I meant  
the other way around -- that we wouldn't want to list foobar.elc as  
depending on the emacs binary as a way of expressing dependence on all  
the macros and functions that were preloaded into that binary.

>> otherwise, someone downloading and
>> building a release will have to recompile all the elisp code
>
> I don't see why.  Please explain.

If foobar.el uses a macro that's defined in subr.el or something else  
that's preloaded, and the macro's definition (or that of some function  
in yet another file that gets invoked during expansion of the macro)  
is changed, we want foobar.el to be recompiled, right?  What should  
foobar.elc be listed as depending on that would trigger this?  The  
choices seem to be subr.{el,elc} (and by extension all the preloaded  
files, unless we can either compute more precise dependencies or  
maintain them properly by hand) or the emacs binary itself.

Compiling a freshly downloaded source tree obviously updates the emacs  
binary's timestamp, so if that's how we express the dependency on  
"whatever is preloaded that we can't compute precise dependencies on",  
everything gets byte compiled at build time, millions of people waste  
millions of extra cycles, electricity usage soars, more oil is burned,  
the greenhouse effect is amplified, and we all die.  (I'm sorry, was  
someone talking about hyperbole earlier?)  So, I think we probably  
don't want to do that.

Which, I think, leaves us indicating that foobar.elc depends on  
subr.elc and friends.

>> On the other hand, we probably don't want to recompile
>> everything because lisp/language/georgian.el changed.
>
> No, we don't, but I don't see how would that happen.  You just need to
> re-dump.

Depends if georgian.el(c) gets listed among the dependencies for all  
the other .elc files, just in case someday it redefines "defcustom",  
kind of like how things would depend on the compiler just in case the  
ABI changes.

Ken