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

[Konstantin Kharlamov <Hi-Angel@yandex.ru>]

On Sun, 2024-11-17 at 17:37 +0200, Eli Zaretskii wrote:
> > Cc: Alan Mackenzie <acm@muc.de>, 74382@debbugs.gnu.org
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Date: Sun, 17 Nov 2024 18:21:36 +0300
> > 
> > On Sun, 2024-11-17 at 08:25 +0100, Gerd Möllmann wrote:
> > > Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:
> > > 
> > > > Sure, I just reproduced it after removing all `.elc` files in
> > > > the
> > > > repo,
> > > > here how:
> > > > 
> > > > 1. `git checkout f2f13fa630b` (a commit from April)
> > > > 2. `make -j$(nproc)` to compile. Note: you don't need to wait
> > > > for
> > > > build
> > > > to finish, I just waited for all files under `lisp/emacs-lisp`
> > > > directory to finish compilation, and then ^C'ed it.
> > > > 3. `git checkout 29098a291f5` (a November commit).
> > > > 4. `make -j$(nproc)`
> > > 
> > > This would always work if lisp/Makefile would rm the .elc files
> > > from
> > > COMPILE_FIRST, right? I suspect this isn't done to speed up the
> > > build
> > > in
> > > the usual case, and because it's a bit difficult to automatically
> > > determine if it has to done or not.
> > > 
> > > Does a "make clean" after the checkout in (3) make it work?
> > 
> > I don't think so, because `make clean` for some reason doesn't
> > remove
> > `.elc` artifacts.
> 
> And it shouldn't, because *.elc files are part of a release tarball.

But if someone decided to build from a release tarball, sure they can
produce .elc files as well, can't they?