bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified

[Gerd Möllmann]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Gerd Möllmann <gerd.moellmann@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.