[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 03:54:28 -0400

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

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

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

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.


reply via email to

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