Subject: Re: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work

From: Spencer Baugh <[email-masked]>
Date: Fri, 11 Jul 2025 17:40:53 -0400

On Thu, Jul 10, 2025 at 5:11 PM Andrea Corallo <[email-masked]> wrote:
>
> Spencer Baugh <[email-masked]> 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.