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

From: Spencer Baugh <[email-masked]>
Date: Tue, 08 Jul 2025 14:25:03 -0400

Eli Zaretskii <[email-masked]> writes:
>> From: Spencer Baugh <[email-masked]>
>> Cc: [email-masked],  [email-masked],  [email-masked]
>> Date: Fri, 13 Jun 2025 11:41:27 -0400
>> 
>> Eli Zaretskii <[email-masked]> writes:
>> > severity 78783 wishlist
>> > thanks
>> >
>> >> Cc: Andrea Corallo <[email-masked]>, [email-masked]
>> >> Date: Fri, 13 Jun 2025 09:34:10 -0400
>> >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <[email-masked]>
>> >> 
>> >> 
>> >> Native compilation of site-lisp directories during the Emacs build
>> >> (e.g. --with-native-compilation=aot) produces .eln files which are
>> >> unused when installed.
>> >
>> > Why are you compiling files in site-lisp during the build?  This is
>> > not supported, and I see no reason why we should extend our build
>> > processes to support it.
>> >
>> > Why cannot you compile site-lisp files after Emacs is built and
>> > installed?
>> 
>> If a site-lisp file is built (whether as part of Emacs or not) and
>> subsequently installed into the site-lisp directory, its file name will
>> change.  That changes the path_hash computed by
>> comp-el-to-eln-rel-filename which will cause this issue.
>> 
>> This is a general problem with AOT-compiling files which are
>> subsequently installed somewhere else.  It applies both for core Emacs
>> files and for site-lisp.
>
> No, core Emacs files are okay and supported.
>
> It's compiling site-lisp files in this way is not supported.  And you
> still haven't answered my question: why do you need that?
>
> 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.