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 #8 received at 74382 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: acm <at> muc.de, 74382 <at> debbugs.gnu.org
Subject: Re: bug#74382: `compile-first` Make rule is no longer using
 `load-prefer-newer`
Date: Sat, 16 Nov 2024 18:27:14 +0200
> Cc: Alan Mackenzie <acm <at> muc.de>
> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> 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.

They are supposed to be stripped only while processing the
compile-first target, and that is on purpose.  See the section
"Target-specific" in the GNU Make manual, where this feature is
documented.




This bug report was last modified 215 days ago.

Previous Next


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