emacs-devel
[Top][All Lists]
Advanced

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

Re: The emacs-28 release branch has been created


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 -0400

     HAVE_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



reply via email to

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