emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building a tarball with native-compilation support


From: Eli Zaretskii
Subject: Re: Building a tarball with native-compilation support
Date: Sat, 07 Aug 2021 09:23:42 +0300

> Date: Fri, 06 Aug 2021 09:05:02 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> 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?

There are some complications with doing this.  For a Makefile target
we need to know the file name of the .eln file to look for.  That file
name includes 2 parts that only Emacs knows: the ABI hash (which
determines the subdirectory of native-lisp/), and the 2 hashes
included in the basename of the .eln file itself.  For example, the
.eln file corresponding to window.el on my machine is this:

   native-lisp/28.0.50-2e9d394d/window-0d1b8b93-dcb2375f.eln

This should be the target name of the Makefile rule.  We can ask Emacs
to provide the hashes (the value of comp-abi-hash and what
comp-el-to-eln-rel-filename returns for "window.el"), but the problem
is that it must be the up-to-date rebuilt Emacs, otherwise the values
could be incorrect, or the Emacs binary could not yet exist at all.
This complicates things because Make expands and calculates some of
the stuff in the Makefile when it reads the Makefile, before it starts
executing the rules, and we cannot guarantee we can know those hashes
at that time.

So I think a better way would be to write a function in Emacs Lisp
that is passed a list of preloaded Lisp files, and natively-compiles
those of them whose *.eln files are either outdated or do not exist.
Then we could have a single Makefile target which invokes this
function once Emacs is fully rebuilt.

Comments?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]