|
From: | Ken Brown |
Subject: | Re: The emacs-28 release branch has been created |
Date: | Sun, 3 Oct 2021 13:14:15 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 |
On 10/3/2021 12:11 PM, Eli Zaretskii wrote:
Cc: emacs-devel@gnu.org From: Ken Brown <kbrown@cornell.edu> Date: Sun, 3 Oct 2021 11:34:31 -0400HAVE_NATIVE_COMP = @HAVE_NATIVE_COMP@I think it's supposed to get that from the top-level Makefile. Doesn't it do that in your builds?No. And both lib/Makefile.in and lisp/Makefile.in include that line.Oops! Should be fixed now, thanks.
I built a tarball and started testing, and I found another bug, this one somewhat non-intuitive: In the recipe for ../native-lisp, "mkdir" needs to be replaced by "$(MKDIR_P)" (or even omitted). The reason is that the native-lisp directory actually exists by the time that recipe is executed.
Suppose you run "make all" in src and the native-lisp directory doesn't exist. Make sees that the prerequisite "../native-lisp" of "all" doesn't exist, so it remembers that it will have to build it after building emacs$(EXEEXT), $(pdmp), and $(OTHER_FILES). But by that time native-lisp exists because of "make compile-first" in the lisp directory.
Here's what I see in my build log before making the change: ./temacs --batch -l loadup --temacs=pbootstrap \ --bin-dest /usr/local/bin/ --eln-dest /usr/local/lib/emacs/28.0.60/ [...] make -C ../lisp compile-first EMACS="../src/bootstrap-emacs.exe" make[2]: Entering directory '/tmp/emacs-28.0.60/lisp' ELC+ELN emacs-lisp/comp.elc ELC+ELN emacs-lisp/comp-cstr.elc [...] LC_ALL=C ./temacs -batch -l loadup --temacs=pdump \ --bin-dest /usr/local/bin/ --eln-dest /usr/local/lib/emacs/28.0.60/ [...]/usr/bin/mkdir ../native-lisp && make --no-print-directory ../lisp/emacs-lisp/autoload.eln ...
... and the mkdir command fails.After making the change, the native compilation of the preloaded files proceeds, and I think everything will be OK. I say "I think", because I ran into fork failures (even on 64-bit Cygwin!), so I'll need to insert rebase commands somewhere before I can test further.
Ken
[Prev in Thread] | Current Thread | [Next in Thread] |