bug#55305: 28.0.50: With async nativecomp, package manager fails to load hyperbole-autoloads.el before compilation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: akrl@sdf.org,  55305@debbugs.gnu.org,  rswgnu@gmail.com,  rsw@gnu.org
> Date: Sun, 15 May 2022 12:47:00 -0400
> 
> > I don't see why comp.el should call package-related functions (or
> > indeed know anything about packages and distinguish between packages
> > and other Lisp files).  It makes no sense to me.  Compilation should
> > not consider user customizations or be dependent on them.
> 
> Compiling a `.el` file requires loading files, running macros, and
> calling functions, all of which may not come with Emacs and may depend
> on the user's specific customizations and set of installed packages
> (regardless of whether they're installed via package.el or some other
> way).
> 
> So in order for the compilation to happen correctly, our async workers
> need to mimic to some extent the currently running Emacs session.

That was never the way byte-compilation worked in Emacs.  We have all
those 'require' and 'eval-when-compile' things precisely so a file can
tell the compiler what is needed for the compilation.  And we _need_ a
way to make the compilation be completely independent of any local
customizations or installed packages.

> My suggested patch adds the call to `package-activate-all` which is
> usually executed in `startup.el` between loading `early-init.el` and
> `init.el` and whose intention is to initialize things for the
> user-installed packages much like things are unconditionally initialized
> for the bundled packages (i.e. enough so it's easy to use them, but
> sufficiently little that it doesn't get in the way if the user doesn't
> want to use the package).

We don't call package-activate-all at startup when Emacs is told to
ignore user and site customizations.  That is NOT an accident, that is
the only way to have *.elc and *.eln files that can be copied to
another system and still work the same.  Changing this makes no sense.

I'm firmly against doing this.

> AFAIK the only way to make async compilation work reliably is to make it
> generate the `.eln` file without using the `.el` file (i.e. using the
> `.elc` file instead, which can be compiled without having to load any
> user-installed file, expand any macro, or run any user-installed
> function).  That will also save us from mis-compiling file and from
> (re)emitting compilation warnings.

This is unrelated, and is an entirely different discussion (which
comes up from time to time, and we didn't yet find a way around the
obstacles).