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

[Eli Zaretskii <eliz@gnu.org>]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org
> Date: Sun, 17 Nov 2024 19:04:42 +0300
> 
> On Sun, 2024-11-17 at 17:53 +0200, Eli Zaretskii wrote:
> > No, Emacs release tarballs come with *.elc files, and users shouldn't
> > recompile them.  For starters, it makes the build significantly
> > longer, besides being unnecessary.
> > 
> > Recompiling *.elc files is only needed if the corresponding *.el
> > files
> > are modified, something that doesn't normally happen when you build a
> > release tarball.
> 
> Okay. So, how about a compromise here: provide release tarball with
> modified Makefiles which upon calling `make clean` would not remove
> `.elc` files — but let `make clean` inside git-repository remove elc
> files?

We already have a special target for that: maintainer-clean.  There's
no need to make such confusing differences between what "make clean"
does in a tarball and in Git.  That's a standard GNU target, so it
should do what the GNU Coding Standards say, and do it consistently.

Removing all the *.elc files (and a few *.el files that are generated
by the build from Git) makes the build much longer, so doing so should
be harder and rarer, not easier and more frequent.

> Users expect `make clean` to remove non-config-related bulid artifacts.
> Which includes `.elc` files. I can't count how many times I was
> forgetting about this peculiarity of Emacs build system, and after
> finding out that even `make clean` doesn't help with build errors (due
> to COMPILE_FIRST files stuff), I had to nuke everything with `git clean
> -fdx`. Even Gerd in this discussion forgot about this peculiarity — and
> Gerd unlike me is a regular Emacs developer.

You will have to get used to this curiosity of the Emacs build system,
sorry.  The main audience of the build stuff in Git is Emacs
developers, so everyone else have to adapt.