Re: Updating *.el files and native compilation

[Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> Andrea,
>
> I'd like to better understand what happens with *.eln files when the
> corresponding *.el files and the Emacs C code are updated and
> recompiled.  There are two use cases here that are relevant:
>
>   . building Emacs as part of development, while keeping old Emacs
>     executables
>
>   . updates to locally installed *.el files (e.g., in site-lisp) that
>     also target multiple Emacs versions
>
> With byte-compilation, we keep only 1 .elc file for each .el file; if
> one starts an Emacs binary which doesn't fit the .elc file, we could
> have Lisp errors when invoking the affected Lisp functions, but in
> general Emacs should not crash.  However, with native-compilation we
> can have several *.eln files in the respective directories (either
> native-comp or eln-cache), even if the ABI hash didn't change.  So my
> questions are:
>
>   . if the .el file changes in incompatible ways, native-compilation
>     will produce a .eln file with a different file name, and each
>     Emacs executable will then load the .eln file with which it is
>     compatible, is that right?

Hi Eli,

that's correct.

>   . if, for some reason, Emacs loads an incompatible .eln file, then
>     some Lisp programs could crash the Emacs session, is that correct?
>     If so, how do we make sure such incompatible changes always cause
>     a new native compilation that yields a different file name for the
>     .eln file?

Yes but this should not happen, every change that can introduce an
incompatibility has to be accounted in the `comp-abi-hash' computation
and AFAIK ATM it is.

> The upshot of all this is that if one keeps multiple Emacs
> executables, it should be safe to invoke each one of them without
> risking crashes due to loading incompatible *.eln files that were
> produced by other, subtly incompatible Emacs executables.  Is this
> indeed safe, or do we have some "gotchas" that still need to be taken
> care of?

As of today I'm not aware of any gotcha here, if we discover a case of
this we should treat it as bug.

Regards

  Andrea