bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS)

[Eli Zaretskii <eliz@gnu.org>]

> From: Matthew Bauer <mjbauer95@gmail.com>
> Date: Sat, 12 Jun 2021 22:13:13 -0500
> Cc: Andrea Corallo <akrl@sdf.org>
> 
> This is similar to bug#48497, but appears to still happen even after
> commit 3f207753a0.
> 
> The basic problem is that the installed lisp path does not match either
> of the search expressions in comp-el-to-eln-rel-filename, meaning that
> native lisp needs to be recompiled needlessly.
> 
> The problem seems to come from PATH_REL_LOADSEARCH being set for me (on
> macOS) to Contents/Resources/lisp, but the lisp files actually being
> installed to
> /nix/store/...-emacs-gcc-20210612.0/share/emacs/28.0.50/lisp (path
> generated by Nix). As a result, comp-el-to-eln-rel-filename used the
> filename comp-034d3699-516ce4bf.eln for comp.el.gz where 516ce4bf is the
> md5sum of the contents of comp.el and 034d3699 is the md5sum of the full
> path of comp.el, not of //emacs-lisp/comp.el (7672a6ed), which is what
> Emacs installs.
> 
> To fix this, I propose using PATH_LOADSEARCH in addition to
> PATH_REL_LOADSEARCH so that we can catch both types of macOS installs
> (.app and unix). I’ve attached a patch which implements this, adding
> relative and absolute loadsearch resolution.

Thanks.

Alan, any comments?

And could you explain to this macOS-illiterate why this mess happens
on macOS?

In any case, if this only happens on macOS, I see no reason to run the
additional code on other systems, it's just waste of cycles.