GNU bug report logs - #74382
`compile-first` Make rule is no longer using `load-prefer-newer`

Previous Next

Package: emacs;

Reported by: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>

Date: Sat, 16 Nov 2024 15:12:02 UTC

Severity: normal

Tags: notabug

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Cc: Alan Mackenzie <acm <at> muc.de>
Subject: `compile-first` Make rule is no longer using `load-prefer-newer`
Date: Sat, 16 Nov 2024 18:11:01 +0300
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.