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

Previous Next

Full log

Message #29 received at 74382 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: acm <at> muc.de, 74382 <at> debbugs.gnu.org
Subject: Re: bug#74382: `compile-first` Make rule is no longer using
 `load-prefer-newer`
Date: Sun, 17 Nov 2024 08:44:26 +0200

> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> Cc: acm <at> muc.de, 74382 <at> debbugs.gnu.org
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.