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

[Konstantin Kharlamov]

On Sat, 2024-11-16 at 20:38 +0200, Eli Zaretskii wrote:
> > Cc: 74382@debbugs.gnu.org
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Date: Sat, 16 Nov 2024 20:45:47 +0300
> > 
> > ## Expected
> > 
> > Build finishes
> > 
> > ## Actual
> > 
> > It fails with stacktrace so huge that it goes beyond Konsole
> > scrollback
> > and with the following message:
> > 
> > 
> >     Loading macroexp.elc (compiled; note, source file is newer)...
> >     Wrong type argument: "../../lisp/emacs-lisp/comp.el", hash-
> > table-p, (#s(byte-to-native-top-level (byte-code
> > "��!���!���!���!���!���!���!���!������%�����DD�����&       
> > �����DD�����&  
> > �����DD���&�����DD�����&������DD�����&������DD�����&������DD�����&�
> > " [require bytecomp cl-lib gv rx subr-x warnings comp-common comp-
> > cstr custom-declare-group ...] 10) t) #s(byte-to-native-top-level
> > (#<symbol defvar at 4425> #<symbol no-native-compile at 4432> nil
> > "Non-nil to prevent native-compiling of Emacs Lisp code.
> >     Note that when `no-byte-compile' is set to non-nil it overrides
> > the value of
> >     `no-native-compile'.
> >     This is normally set in local file variables at the end of the
> >     Emacs Lisp file:
> 
> I don't think this is related to what lisp/Makefile does.  When
> macroexp.el is updated, builds are known to fail until you remove
> macroexp.elc (or bootstrap).

Okay, but why you need to remove macroexp.elc, isn't it the build
system job to rebuild it when it's changed? I think so, and the
macroexp.el is among the `COMPILE_FIRST` files in lisp/Makefile.in.