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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: Alan Mackenzie <acm@muc.de>
> From: Konstantin Kharlamov <Hi-Angel@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.