Re: The emacs-28 release branch has been created

[Ken Brown <kbrown@cornell.edu>]

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