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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acorallo <at> gnu.org, 78783 <at> debbugs.gnu.org, app-emacs-dev <app-emacs-dev <at> janestreet.com>
Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work
Date: Wed, 9 Jul 2025 10:13:48 -0400

[Message part 1 (text/plain, inline)]

On Wed, Jul 9, 2025, 9:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Date: Wed, 9 Jul 2025 09:17:41 -0400
> > Cc: acorallo <at> gnu.org, 78783 <at> debbugs.gnu.org,
> >       app-emacs-dev <app-emacs-dev <at> janestreet.com>
> >
> >  > > The supported way of compiling site-lisp files is after they are
> >  > > installed in site-lisp.
> >  >
> >  > This makes it difficult to develop code that will be installed in
> >  > site-lisp, because code which is not installed cannot be tested with
> the
> >  > native-compilation that will be used when that code is actually
> >  > installed.  Since there are sometimes bugs in packages when used with
> >  > native compilation, it would be better to be able to run the code
> before
> >  > it is installed with the same native-compilation artifacts that will
> be
> >  > used when it is installed.
> >
> >  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.

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.

>

[Message part 2 (text/html, inline)]

Previous Next

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