unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Andrea Corallo <akrl@sdf.org>
Cc: emacs-devel@gnu.org
Subject: Updating *.el files and native compilation
Date: Sat, 08 May 2021 10:51:15 +0300	[thread overview]
Message-ID: <83mtt5acjw.fsf@gnu.org> (raw)

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?

  . 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?

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?

Thanks.



             reply	other threads:[~2021-05-08  7:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08  7:51 Eli Zaretskii [this message]
2021-05-10  7:35 ` Updating *.el files and native compilation Andrea Corallo via Emacs development discussions.
2021-05-10 13:34   ` Eli Zaretskii
2021-05-10 15:44     ` Andrea Corallo via Emacs development discussions.
2021-05-10 16:59       ` Eli Zaretskii
2021-05-10 20:45         ` Andrea Corallo via Emacs development discussions.
2021-05-11  2:27           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83mtt5acjw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=akrl@sdf.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).