GNU bug report logs -
#78783
30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work
Previous Next
Full log
View this message in rfc822 format
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&
Andrea
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.