GNU bug report logs - #57152
29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <akrl <at> sdf.org>, 57152 <at> debbugs.gnu.org
Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified
Date: Wed, 17 Aug 2022 15:50:35 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Could it be that src/Makefile is simply not invoked after lisp/Makefile
>> has built loaddefs.*? In Makefile.in we have
>>
>> SUBDIR = $(NTDIR) lib lib-src src lisp
>> ...
>> all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid)
>>
>> That is src comes before lisp.  Haching something like a second 'make
>> -C' at the end seems to do something not entirely unreasonable.
>
> Hm, interesting...  but I think we might end up in a situation where we
> first build the Emacs executable, then update the loaddefs.el, and then
> build the Emacs executable again.

I haven't observed that with your 'echo ...>>foo.el; make' example.

But wouldn't that be a hint that there is something fishy in
src/Makefile?  Or incomplete, or something?

>
> But perhaps that's OK -- while we're scanning for new loaddefs every
> build, there's seldom any new ;;;###autoloads, so the loaddefs.el file
> doesn't update all that often.
>
> I'm not quite sure where the second "make -C" would go, though.

I did it this way:

diff --git a/Makefile.in b/Makefile.in
index bf0f52b514..78103f897f 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -358,10 +358,17 @@ ELN_DESTDIR =
 
 gsettings_SCHEMAS = etc/org.gnu.emacs.defaults.gschema.xml
 
-all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid)
+all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid) src-depending-on-lisp
 
 .PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force-ns-self-contained etc-emacsver
 
+# Changes in lisp may require us to reconsider the build in src.  For
+# example, if loaddefs.{el,elc} were built in lisp, we need a new
+# .pdmp containing the new autoloads.
+.PHONY: src-depending-on-lisp
+src-depending-on-lisp: lisp
+	${MAKE} -C src
+
 # If configure were to just generate emacsver.tex from emacsver.tex.in
 # in the normal way, the timestamp of emacsver.tex would always be
 # newer than that of the pdf files, which are prebuilt in release tarfiles.


The dependency on lisp in src-depending-on-lisp is necessary to make
sure it runs after lisp has been built.  Maybe there is a clever trick
to express "only if loaddefs has been regenerated" in some way, but
'make -C src' is quite fast already if it hasn't to do anything, at
least compared to other things.

There is one pretty strange thing though, which I can't explain.  I once
got an error "trying to load incoherent eln" which is mentioned in
bug#45103.  I can't say much else about this though, not even what the
cause of this might be.  It was a build with -j8 if that matters.  Maybe
elns are modified during dumping, so that a second dump cannot be done?
But that wouldn't explain why it succeeds most of the time.  No idea,
and not easily reproducible, alas.

CC'ing Andrea.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.