GNU bug report logs -
#74382
`compile-first` Make rule is no longer using `load-prefer-newer`
Previous Next
Full log
Message #44 received at 74382 <at> debbugs.gnu.org (full text, mbox):
On Sun, 2024-11-17 at 17:37 +0200, Eli Zaretskii wrote:
> > Cc: Alan Mackenzie <acm <at> muc.de>, 74382 <at> debbugs.gnu.org
> > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > Date: Sun, 17 Nov 2024 18:21:36 +0300
> >
> > On Sun, 2024-11-17 at 08:25 +0100, Gerd Möllmann wrote:
> > > Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
> > >
> > > > Sure, I just reproduced it after removing all `.elc` files in
> > > > the
> > > > repo,
> > > > here how:
> > > >
> > > > 1. `git checkout f2f13fa630b` (a commit from April)
> > > > 2. `make -j$(nproc)` to compile. Note: you don't need to wait
> > > > for
> > > > build
> > > > to finish, I just waited for all files under `lisp/emacs-lisp`
> > > > directory to finish compilation, and then ^C'ed it.
> > > > 3. `git checkout 29098a291f5` (a November commit).
> > > > 4. `make -j$(nproc)`
> > >
> > > This would always work if lisp/Makefile would rm the .elc files
> > > from
> > > COMPILE_FIRST, right? I suspect this isn't done to speed up the
> > > build
> > > in
> > > the usual case, and because it's a bit difficult to automatically
> > > determine if it has to done or not.
> > >
> > > Does a "make clean" after the checkout in (3) make it work?
> >
> > I don't think so, because `make clean` for some reason doesn't
> > remove
> > `.elc` artifacts.
>
> And it shouldn't, because *.elc files are part of a release tarball.
But if someone decided to build from a release tarball, sure they can
produce .elc files as well, can't they?
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.