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

[Jim Myhrberg <contact@jimeh.me>]

Here they are:

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

"/Users/jimeh/Projects/build-emacs-for-macos/sources/emacs-mirror-emacs-5b41545"
is obviously my local source/build directory that my build script
extracts the source tarball to and builds from.

On Mon, Sep 21, 2020 at 8:53 AM Andrea Corallo <akrl@sdf.org> wrote:
>
> Jim Myhrberg <contact@jimeh.me> writes:
>
> > 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.
>
> Hi Jim,
>
> I think we should be able to improve the filename hashing mechanism on
> MacOS to deal with that.  Perhaps something like removing
> */Emacs.app/Contents/MacOS/ from the input of it.
>
> Could you post the value of PATH_DUMPLOADSEARCH and PATH_LOADSEARCH
> macros?  You should find them defined in epaths.h in your build
> directory.
>
> Thanks
>
>   Andrea