Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org >> Date: Sat, 29 Apr 2023 08:19:35 +0000 >> >> >> 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. > > Compilation? Setup? Scraping for auto-loads doesn't have anything to do with "compiling" (and might be confused with byte compilation). "Setup" might be imaginable, I will think about it. > "Building" is a strange term when we are talking about a Lisp package. How come? >> > 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. > > That is definitely a bug. But a package without autoloads is still a > valid use case, and we should support it. > >> 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: > > What happens if a package has no autoloads? The doc string says in > that case passing EXTRA-DATA will produce OUTPUT-FILE regardless. > Does your patch handle that? (It's hard to tell, given all the > whitespace changes in the patch.) It would, as the else-case of the if branch I am proposing to eliminate would still insert the EXTRA-DATA. Here is a patch generated without any whitespace changes: