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

From: Konstantin Kharlamov <[email-masked]>
Date: Sun, 17 Nov 2024 18:31:38 +0300

On Sun, 2024-11-17 at 08:44 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <[email-masked]>
> > Cc: [email-masked], [email-masked]
> > Date: Sun, 17 Nov 2024 01:54:48 +0300
> > 
> > > It's impractical, because we have many files with macros. 
> > > Tracking
> > > all of those dependencies would mean that changes in any file
> > > will
> > > trigger unnecessary recompilation of many other files.  If you
> > > don't
> > > mind spending that time waiting for the build, just "make
> > > bootstrap"
> > > every time you update from Git, and you will have that.
> > 
> > Unless I'm missing something, the problem seems to be with one
> > exact
> > file, macroexpand.elc, and not with others.
> 
> No, that's not true.  I had similar problems with basically all the
> files in COMPILE_FIRST.
> 
> More importantly, what you seem to be missing is that we deliberately
> play with the time stamps of the *.elc files in COMPILE_FIRST (search
> for "UTC" in the Makefile), so we must not use load-prefer-newer in
> this case.  That is the reason why it's removed from
> BYTE_COMPILE_FLAGS.
> 
> > So the algorithm is simple: if `macroexpand.el` was modified,
> > remove
> > its elc file. You don't need to track any dependencies.
> 
> How will load-prefer-newer help if this is what you do?  That's the
> trigger for this bug report, no?
> 
> In any case, this is not the reason why load-prefer-newer is removed
> while we COMPILE_FIRST; see above.

Alright, for more efficient discussion I think I need to dig into how
this all work in different situations and measure performance, to come
up with some suggestions, but I'm afraid ATM I just don't have the
spare time, so maybe let's close the discussion for now…

I just see that COMPILE_FIRST files should never be used while being
stale, but for performance reasons they are used stale. I don't think
this is the case where the correctness can be traded off for
performance, but it's just my opinion.