On Wed, Jul 9, 2025, 9:53 AM Eli Zaretskii wrote: > > From: Spencer Baugh > > Date: Wed, 9 Jul 2025 09:17:41 -0400 > > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, > > app-emacs-dev > > > > > > 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. >