Re: Building a tarball with native-compilation support

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> I think we have an unsolved issue for when we will release an Emacs
> tarball that supports native-compilation: how to compile the preloaded
> *.el files natively at build time.  This has to be done on the machine
> where the tarball is built, because the *.eln files are
> architecture-dependent, and thus cannot be in the source tarball.
>
> Currently, compiling the preloaded *.el into *.eln is a side effect of
> byte-compilation, so a new .eln file is produced when the *.el file is
> newer than the corresponding .elc file, which causes Make to invoke
> the byte+native-compilation.  But in a release tarball, all *.elc
> files are newer than the corresponding *.el files, so this Make rule
> will not be triggered, and the *.eln files will not be produced.  So
> Emacs will be dumped with byte-compiled *.elc files, which is not what
> we want, I think.
>
> So unless I'm missing something, we need some Make wizardry to trigger
> native-compilation at build time, even if the corresponding *.elc
> files don't need to be re-generated.
>
> Comments?

Hi Eli,

IIUC in the release tarballs we precompile .el files but not the .c one
as indeed this is arch specific.

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?

Thanks

  Andrea