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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: acorallo <at> gnu.org, 78783 <at> debbugs.gnu.org, app-emacs-dev <at> janestreet.com
Subject: Re: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs
 build doesn't work
Date: Thu, 10 Jul 2025 16:04:23 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Thu, 10 Jul 2025 06:09:20 -0400
> Cc: acorallo <at> gnu.org, 78783 <at> debbugs.gnu.org, 
>  	app-emacs-dev <app-emacs-dev <at> janestreet.com>
> 
>    You haven't explained why you cannot natively-compile the
>  files after the build is complete, directing the *.eln files to some
>  shared directory, and package those *.eln files together with the rest
>  of the built Emacs.
> 
> Because the native compilation doesn't just need to happen after the build is complete, but also after Emacs
> is installed, because comp-el-to-eln-rel-filename refuses to use native compilation artifacts that were
> produced before Emacs was installed, because of its strict filename checking.  Except that it has a special
> exception for .el files shipped with Emacs, which could be extended to site-lisp.

I don't understand what you are saying.  I feel there's a
misunderstanding here.

My suggestion above was to natively-compile those files _after_ you
run "make install", directing the *.eln files to the same directory
where the Emacs installation places the*.eln files produced by the
build.

>  > I can indeed locally patch comp-el-to-eln-rel-filename to ignore
>  > part of the filename for files under PATH_SITELOADSEARCH, and that's
>  > my current plan, if you think this is reasonable.
> 
>  I don't think it's reasonable, but it's your distribution and your
>  users you are putting at risk.
> 
> Why isn't it reasonable?  Andrea has previously commented in other bugs that the file name check is not
> very important in the first place; it's not about correctness, it's just a convenience for avoiding conflicts
> during parallel compilation.  Honestly the file name check could probably be removed entirely, as it has
> already been weakened in other bugs.

That check is to minimize the risk of loading incompatible *.eln
files.

Previous Next

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