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

[Konstantin Kharlamov]

On Sun, 2024-11-17 at 18:29 +0200, Eli Zaretskii wrote:
> > 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.

GNU Coding Standard section for `make clean` says, quoting:

> Delete all files […] that are normally created by building the
program. However, don’t delete the files that record the configuration.
Also preserve files that could be made by building, but normally aren’t
because the distribution comes with them.

The "git distribution" doesn't come with .elc files, hence .elc files
should be removed by `make clean` if run in the git repository. That's
what the standard says.

> 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.

You are optimizing for the wrong people. The auditory for release
tarballs are package maintainers, and they couldn't care less if `make
clean` removes all artifacts or not, because: 1. Nowadays the majority
don't package on their personal machines anyway and use CI, and 2. they
don't typically execute `make clean`.

This "don't clean elc files during `make clean`" hurts Emacs devs and
contributors, while gaining nothing in return.

> > 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.

I don't think Emacs developers are using release tarballs, so this
"curiosity" isn't helping them.