GNU bug report logs -
#78783
30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work
Previous Next
Full log
Message #37 received at 78783 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jul 9, 2025 at 11:52 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Date: Wed, 9 Jul 2025 10:13:48 -0400
> > Cc: acorallo <at> gnu.org, 78783 <at> debbugs.gnu.org,
> > app-emacs-dev <app-emacs-dev <at> janestreet.com>
> >
> > On Wed, Jul 9, 2025, 9:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > Emacs 30 and later has the emacs-lisp-native-compile command, which
> > > can be used to compile the file visited in the current buffer. The
> > > companion command emacs-lisp-native-compile-and-load will also load
> > > the resulting .eln file. I think these two commands can be used to
> > > test the results of natively-compiling any Lisp file, anywhere.
> > >
> > > Yes, but then those native compilation artifacts aren't the ones which will actually be used when
> > Emacs is
> > > installed. So there is the possibility of differences between them, which can cause bugs which aren't
> > caught
> > > by testing only the uninstalled version.
> >
> > Every file you install on the end-user machine is never the same as
> > the one you tested on your development machine. And yet we don't say
> > they cannot be tested.
> >
> > When I compile a .o on my machine and then copy it to a user machine and run it there, it is the same file,
> > because it has the same contents and the same name.
>
> You can only do that if the other machine has exactly the same
> architecture and the same versions of system libraries. See bug#78907
> for what happens otherwise.
Yes, of course. But this is how package managers work: they provide
binaries that are compiled on one machine and then installed on many
user machines, and this works because they are careful to use binaries
on the same architecture and with the same system libraries.
> > So I don't see the difference here, and don't understand why we are
> > splitting hair. The problems you raise are barely tangible at best.
> >
> > The other issue is that in my build system, when automated tests are run they are run in a temporary
> > directory with a randomized name. This means that the native compilation has to happen separately in
> > every test. This is much too slow; it would be better to be able to native compile once and share that native
> > compilation between all tests, like can be done with byte compilation.
>
> If you are trying to argue that we should give up the strict testing
> which is precondition for loading a .eln file, then it's not going to
> happen, sorry. Crashing an Emacs session due to some
> incompatibilities we avoid this way is a much higher price to pay than
> what you describe, even if there's no better solutions within the
> current restrictions.
The strict testing done by comp-el-to-eln-rel-filename is deliberately
weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOADSEARCH:
part of the filename is ignored and not checked. I am simply
suggesting that we should do the same exact thing for files under
PATH_SITELOADSEARCH.
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.