GNU bug report logs -
#74382
`compile-first` Make rule is no longer using `load-prefer-newer`
Previous Next
Full log
Message #38 received at 74382 <at> debbugs.gnu.org (full text, mbox):
On Sun, 2024-11-17 at 08:44 +0200, Eli Zaretskii wrote:
> > 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.
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.
This bug report was last modified 216 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.