Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org >> Date: Fri, 28 Apr 2023 18:22:43 +0000 >> >> Eli Zaretskii writes: >> >> > What is meant by "building the package"? Is it just compiling the >> > Lisp files? >> >> >From `package-vc-rebuild': >> >> Rebuilding an installation means scraping for new autoload >> cookies, re-compiling Emacs Lisp files, building and installing >> any documentation, downloading any missing dependencies. > > Thanks. As a tangent: this is confusing terminology, so it is > unfortunate that it was selected for this operation. Is there a different way you would have put this? What we do here is sort of combining the steps that the ELPA server and a local package-install do into one, and in my mind this constitutes building software. >> >> (time-less-p output-time >> >> (file-attribute-modification-time >> >> (file-attributes file))) >> >> --8<---------------cut here---------------end--------------->8--- >> >> >> >> does not hold >> > >> > Why would it not hold? Updating from VCS should update the timestamp >> > of the updated files. >> >> I don't think this necessarily holds if there were no changes affecting >> a file. > > I don't follow: a file that didn't change doesn't need its autoloads > updated, right? Right, but if we want to add some additional code to the autoloads (as we are with package.el, when injecting load-path modification), then loaddefs-generate does not re-use the old data, and instead just throws it away and creates a new file with contents of EXTRA-DATA, but without any autoload information. And I have checked, the only place where `loaddefs-generate' is invoked with EXTRA-DATA, is in `package-generate-autoloads'. So the fact that all other places where this function work as intended makes sense. >> >> Another idea is just to get rid of this faulty optimisation. From my >> >> tests this would also resolve the bug. >> > >> > I don't yet understand what optimization is that, but getting rid of >> > it should not alter what the code does for the loaddefs files inside >> > the Emacs tree, because there it does work, and I don't want to touch >> > that. >> >> Are you sure it does work? > > It works well in the Emacs tree, I'm sure. So if it doesn't in this > case, I'd encourage some debugging, because it could be that this is > some subtle bug or feature in loaddefs-generate, and we should > investigate that and fix whatever needs fixing now, since this > function is new in Emacs 29. I think the central issue here is the (and (not defs) extra-data) check. Just because we did not find any new definitions to autoload /and/ EXTRA-DATA is non-nil, does not mean the old contents should be discarded. The else-case already does the right thing, so I really do think that getting rid of the `if' could resolve the issue: