GNU bug report logs -
#74382
`compile-first` Make rule is no longer using `load-prefer-newer`
Previous Next
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
CC: Alan Mackenzie, author of the change in 10083e788f7349fa363d100687dc3d94bea88f57
I've seen for a long time Emacs master builds fail from time to time in spectacular
ways after updating the repo, sometimes so badly that `make clean` doesn't help.
I never dug into that though, but I'm attributing this to the occasional build
messages similar to:
Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/comp.el’ newer than byte-compiled file; using older file
Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/bytecomp.el’ newer than byte-compiled file; using older file
Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/comp-cstr.el’ newer than byte-compiled file; using older file
…which makes sense, because if the repo changed `comp.el` API and Emacs during the
build of newer files is trying to make use of older `.elc` file and hence the older
API, it may result in failure.
Got some spare time today, dug into one of the messages. From what I understand it's
caused by this line `lisp/Makefile.in`:
# ... but we must prefer .elc files for those in the early bootstrap.
compile-first: BYTE_COMPILE_FLAGS = $(BYTE_COMPILE_EXTRA_FLAGS)
From what I understand, this rewrites BYTE_COMPILE_FLAGS to be an empty variable,
which results in `(setq load-prefer-newer t)` being stripped off of the build.
The straightforward solution is to remove this line. But since the line's commentary
opposes to such solution, I'm starting up a discussion what exactly should be the
behavior here 😊
This bug report was last modified 216 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.