|
From: | Jim Myhrberg |
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: | 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 <akrl@sdf.org> wrote: > > Jim Myhrberg <contact@jimeh.me> 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
[Prev in Thread] | Current Thread | [Next in Thread] |