GNU bug report logs - #78783
30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Fri, 13 Jun 2025 13:35:02 UTC

Severity: wishlist

Found in version 30.1.50

Full log


View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: app-emacs-dev <at> janestreet.com, 78783 <at> debbugs.gnu.org
Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work
Date: Fri, 11 Jul 2025 17:40:53 -0400
On Thu, Jul 10, 2025 at 5:11 PM Andrea Corallo <acorallo <at> gnu.org> wrote:
>
> Spencer Baugh <sbaugh <at> janestreet.com> writes:
>
> > Native compilation of site-lisp directories during the Emacs build
> > (e.g. --with-native-compilation=aot) produces .eln files which are
> > unused when installed.
> >
> > The reason is that the absolute file name of the site-lisp directory
> > differs between build-time and install-time, and therefore
> > comp-el-to-eln-rel-filename computes a different path hash for the files
> > contained in site-lisp at build-time and at install-time.
> >
> > The same issue would affect AOT native compilation of all Lisp in Emacs,
> > except that there's a workaround built into comp-el-to-eln-rel-filename,
> > as explained by this comment:
> >
> >      As installing .eln files compiled during the build changes their
> >      absolute path we need an hashing mechanism that is not sensitive
> >      to that.  For this we replace if match PATH_DUMPLOADSEARCH or
> >      *PATH_REL_LOADSEARCH with '//' before computing the hash.
> >
> > In other words, file names containing e.g. "30.1.50/lisp", like
> > "/usr/local/share/emacs/30.1.50/lisp/foo.el", are transformed to
> > "//foo.el" before the path hash is computed.
> >
> > I suggest the same should be done for file names containing
> > "30.1.50/site-lisp".  That would resolve the problem and allow site-lisp
> > to actually be AOT-compiled.
>
> Mmmmh I don't think it would work as AFAIU not all distros embed the
> version in the path:
>
> https://fedoraproject.org/wiki/QA%3ATestcase_emacs_filesystem
>
> https://build.opensuse.org/projects/editors/packages/emacs/files/macros.emacs?expand=0&

Yes, I concretely am suggesting we look at PATH_SITELOADSEARCH so we
respect whatever the distro has ./configure'd, not just hardcode
"30.1.50/site-lisp".

That would allow any distro to ship code in site-lisp and also ship
pre-compiled .elns for that code, without having to perform native
compilation *after* this installation, which is generally much easier.

Thanks for looking at this.




This bug report was last modified 68 days ago.

Previous Next


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