Re: Building a tarball with native-compilation support

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> Date: Thu, 05 Aug 2021 21:55:30 +0000
> 
> IIUC in the release tarballs we precompile .el files but not the .c one
> as indeed this is arch specific.

That's correct.

> Now I'm asking my self:
> 
> - given that as you mentioned the .eln will have to be produced in the
>   target machine
> - given that producing .eln can produce at the same
>   time also the corresponding .elc
> 
> Does it make sense to still precompile and distribute the .elc files to
> the users?  The reason for that is to keep one single release tarball
> that can serve native and non native builds or there are other reasons?

Yes, there are valid reasons to have the *.elc files in the tarball:

  . They make the build faster, because the step of using only *.el
    for COMPILE_FIRST is avoided;
  . They are a must if the user wants Emacs without native-compilation
    support, and in that case make the build extremely fast;
  . They provide canonical *.elc files produce on a system where most
    of the *.el files can be meaningfully byte-compiled because the
    related functionality is supported.

I think if we come up with a way to perform only the
native-compilation of a .el file when the corresponding .elc already
exists, the build will also faster, because we will use the
byte-compiled comp.elc and comp-cstr.elc, not the *.el files.

So I think we should work in this direction, and not decide to work
around the issue by omitting *.elc from the tarball.

How about if we start by providing a separate Makefile target to
native-compile a single .el file when its .elc exists and is
up-to-date?