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

From: Jim Myhrberg <[email-masked]>
Date: Mon, 5 Oct 2020 00:17:42 +0100

Haha, apologies for the nightmare. There are few things worse than
writing code you can't actually test and run yourself
<insert-some-form-of-nightmare-emoji>

With 915214a the application is now structured correctly, but I'm
afraid it doesn't look to be truncating the paths correctly during the
initial build process. As the *.eln files bundled into the app bundle
during the build process with NATIVE_FULL_AOT=1 are ignored. But *.eln
files dynamically compiled into the user eln-cache directory are
re-used regardless of where you place the application on disk.

And relevant stuff from epaths.h just to be safe:

#define PATH_LOADSEARCH
"/Users/jimeh/Projects/build-emacs-for-macos/sources/emacs-mirror-emacs-915214a/nextstep/Emacs.app/Contents/Resources/lisp"
#define PATH_REL_LOADSEARCH "Contents/Resources"
#define PATH_DUMPLOADSEARCH
"/Users/jimeh/Projects/build-emacs-for-macos/sources/emacs-mirror-emacs-915214a/lisp"

And thanks again for all your work :)

On Sun, Oct 4, 2020 at 9:54 PM Andrea Corallo <[email-masked]> wrote:
>
> Jim Myhrberg <[email-masked]> writes:
>
> > Thanks Andrea,
> >
> > I just created a build from commit 44ef243, and it did not work out
> > quite as expected :)
>
> This 43532 is becoming my nightmare :)
>
> 915214ac9a should fix.
>
> Thanks for testing.
>
>   Andrea