GNU bug report logs - #48994
28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS)

Previous Next

Full log

Message #11 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48994 <at> debbugs.gnu.org, Matthew Bauer <mjbauer95 <at> gmail.com>, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Sun, 13 Jun 2021 17:37:55 +0100

On Sun, Jun 13, 2021 at 09:37:15AM +0300, Eli Zaretskii wrote:
> > From: Matthew Bauer <mjbauer95 <at> gmail.com>
> > Date: Sat, 12 Jun 2021 22:13:13 -0500
> > Cc: Andrea Corallo <akrl <at> 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?

I suggested previously we handle this like we do the other install
paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m),
but Andrea didn't like that solution.

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

It's because we support both a relocatable application format and a
normal unix style install. In the .app case the path to the installed
files has to be configured at run-time (although I think Andrea used a
directory relative to the executable), but in the unix case it's
hard-coded.

FWIW, we will have exactly the same problems with GNUstep builds,
because they use the same .app format.

-- 
Alan Third

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.