Re: Source file '.../killer-source.el' newer than byte-compiled file

[Emanuel Berg <moasenwood@zoho.eu>]

Eli Zaretskii wrote:

> Just ignore those messages, really. They are
> mostly harmless. You could compile the
> dependent file again if you want, but that is
> rarely needed, mainly when they define macros
> that were changed, and those macros are used
> by the files which require a.el.

I think you are right, because if you weren't,
this should have broken my system one zillion
times by now, and that hasn't happened, but
I don't understand why. Because think of this
scenario:

First, a.el is the file that `require' b, so
b is `provide'd in b.el.

Both a.el and b.el are edited, a.el w/o bugs,
b.el *with* bugs.

a.el is compiled before b.el is compiled.

When a.el is compiled, it requires b, so,
depending on the variable `load-prefer-newer'
it either gets the buggy b.el _or_ the old
b.elc. Because I never touched the variable,
which defaults to `nil', a.el will get the
old b.elc.

Now, because b.elc exists, it doesn't come with
bugs, as I would have seen that when I compiled
it last time. So a gets a bug-free, but old,
version of b.

Now the compiler comes to b.el and tells me
there is a bug in the file. I fix that bug and
it compiles into a new, bug-free b.elc.
However a.elc is newer than a.el, so a.el won't
recompile to get the new version!

So c.el compiles, and it also requires b.
Now there is no warning from the byte-compiler
since b.elc is newer than b.el. _But_ c got
another version of b.elc than did a!

What does this situation mean?

-- 
underground experts united
http://user.it.uu.se/~embe8573