unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jim Myhrberg <contact@jimeh.me>
To: 43532@debbugs.gnu.org
Subject: bug#43532: [feature/native-comp] *.eln file name hashing algorithm doesn't seem to play nice with NATIVE_FULL_AOT and self-contained Emacs.app builds for macOS
Date: Sun, 20 Sep 2020 14:02:44 +0100	[thread overview]
Message-ID: <CAGaZ61vCayWTdNBnx51tyP=x-aanUVvcBeXm99edQRWzM_Tk6w@mail.gmail.com> (raw)

Hi,

TL;DR:

If I've understood correctly, the filename of the cached *.eln files
includes a hash based on the absolute file path and content of the
source *.el/*.el.gz file. On macOS when producing a self-contained
Emacs.app bundle this means that the cached *.eln files bundled into
the app cannot be used, as their absolute path won't match what they
were during build time. And app bundles on macOS can be placed and
launched from anywhere on disk.

I'm not sure what the best solution here might be. But if the actual
content of the file is used to produce the hash, maybe there's no need
to use the full absolute file path, and instead just the filename
itself, along with the content?

The Long Version:

I'm not sure how familiar people here might be with macOS application
bundles, so here's a brief summary just in case; Application bundles
are self-contained macOS GUI applications which can be launched by for
example double clicking on them, among other ways. On a technical
level, they're simply a folder called "<AppName>.app" which contains
all assets needed to run the application. The main executable is
"<AppName>.app/Contents/MacOS/<AppName>".

In the case of building a self-contained Emacs.app on macOS, it looks
the *.eln caches are generated for the files located in
"<workdir>/nextstep/Emacs.app/Contents/Resources/lisp", and the *.eln
cache folder is
"<workdir>/nextstep/Emacs.app/Contents/MacOS/lib/emacs/28.0.50/native-lisp".
Which means the full set of *.eln caches can only be used when
launched from within the Emacs source directory where you built the
application.

Typical usage on macOS would have the Emacs.app movied/copied to the
"/Applications" folder, but there's no guarantee about that, as
applications are supposed work fine regardless of where it's located
on disk they're located.

I've done some tests while using NATIVE_FULL_AOT=1, which produces
1,572 *.eln files within Emacs.app. But when starting emacs with my
config, it starts by compiling a whole bunch of files from
"Emacs.app/Contents/Resources/lisp/", like "emacs-lisp/cconv.el.gz",
"emacs-lisp/bytecomp.el.gz", "help-mode.el.gz", and others. If I grab
the new *.eln files it produced in my user cache, and move them to
within Emacs.app, it doesn't compile them on launch again. If I then
move Emacs.app to another location on disk, it does compile them
again, as the absolute path has changed.

However there's 83 *.eln files which are loaded from Emacs.app,
because if they're removed, it fails to start at all with a dlopen
error instead. I don't know enough about the internals of Emacs, but
I'd assume they are referred to from the dump file, while the others
are loaded up due to my config requiring them, at which point a cache
miss happens due to the absolute path yielding a different change
filename.


Thanks :)





             reply	other threads:[~2020-09-20 13:02 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-20 13:02 Jim Myhrberg [this message]
2020-09-21  7:53 ` bug#43532: [feature/native-comp] *.eln file name hashing algorithm doesn't seem to play nice with NATIVE_FULL_AOT and self-contained Emacs.app builds for macOS Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21  9:19   ` Jim Myhrberg
2020-09-21 10:26     ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 13:02       ` Jim Myhrberg
2020-09-21 13:41         ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 18:54           ` Jim Myhrberg
2020-09-21 19:38         ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 21:17           ` Jim Myhrberg
2020-09-21 22:40             ` Jim Myhrberg
2020-09-22  7:58             ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22  9:43               ` Jim Myhrberg
2020-09-22 10:21                 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 11:37                   ` Jim Myhrberg
2020-09-22 13:00                     ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-29 15:52 ` bug#43532: [feature/native-comp] *.eln file name hashing, algorithm doesn't seem to play nice with NATIVE_FULL_AOT and self-contained, " Aloxaf
2020-09-29 18:46   ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-29 19:48     ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]       ` <CA+6YrQz8QcASrajz-+QVS5p68VPhQy1Me2T179CzXADn72WYXg@mail.gmail.com>
2020-09-30  7:13         ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]           ` <efd04f70-ced3-9978-2280-2bb41ca14a2f@gmail.com>
2020-10-01 13:19             ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-01 15:01               ` Aloxaf
2020-10-01 15:40                 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-04 18:04                   ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-04 19:54                     ` Jim Myhrberg
2020-10-04 20:54                       ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-04 23:17                         ` Jim Myhrberg
2020-10-05  6:56                           ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-05  9:57                             ` Jim Myhrberg
2020-10-05 15:09                               ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-07  4:09                     ` Aloxaf Yin
2020-10-07 15:00                       ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-08  3:40                         ` Aloxaf Yin
2020-10-14  0:12 ` Andrew Whatson
2020-10-14  6:57   ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-15  9:38     ` Andrew Whatson
2020-10-15 10:54       ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-15 12:04         ` Andrew Whatson
2020-10-15 12:56           ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-15 13:11             ` Jim Myhrberg
2020-10-15 14:51             ` Aloxaf Yin
2020-10-15 15:02               ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-15  6:52 ` bug#43532: [PATCH] Fix timestamp check when loading from eln (bug #43532) Andrew Whatson

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='CAGaZ61vCayWTdNBnx51tyP=x-aanUVvcBeXm99edQRWzM_Tk6w@mail.gmail.com' \
    --to=contact@jimeh.me \
    --cc=43532@debbugs.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).