bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#55305: 28.0.50: With async nativecomp, package manager fails to load


From: Robert Weiner
Subject: bug#55305: 28.0.50: With async nativecomp, package manager fails to load hyperbole-autoloads.el before compilation
Date: Thu, 12 May 2022 02:21:37 -0400

On Thu, May 12, 2022 at 1:51 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Robert Weiner <rsw@gnu.org>
> Date: Thu, 12 May 2022 01:14:58 -0400
> Cc: 55305@debbugs.gnu.org
>
>  Do the *.el files that produce the error 'require' or 'load'
>  hyperbole-autoloads?
>
> No, the Emacs package manager installation process generates that file from the ;;;###autoload annotations
> in Hyperbole lisp files (see the 'package--make-autoloads-and-stuff' function in "package.el").  The package
> manager also sets up at package activation time to have those autoloads loaded prior to loading any other
> code from the Hyperbole package.

Does this last fact mean there's an assumption in Hyperbole that the
package is always activated before its *.el files are compiled?  If
so, perhaps this is why it fails during native-compilation, where the
package is not activated prior to the compilation?

Said another way, there is an assumption that the hyperbole-autoloads.el file is loaded prior to any compilation, yes.  This is similar to assumptions that loaddefs.el are loaded prior to their reference in other Emacs Lisp files.  The point of the autoloads file is to include definitions that must exist in the Lisp environment prior to their reference in any Lisp files, whether this is during package use or package build-time.


And why would such an assumption, if it exist, make sense?  It seems
to me like the ability to compile a .el file should require activation
of any package, or what am I missing?

I am not saying that the package must be activated prior to compilation but just that there must be an additional hook provided that forces loading of the autoloads prior to any build/compilation of the package (whether byte compilation or native compilation).  Otherwise the build process will generate errors because the autoload definitions will not exist, e.g. maybe an autoloaded variable meant to be global to the package is referenced at the top-level of a package Lisp file.  Complex packages have complex dependencies that I would say cannot all be handled with requires; otherwise, there would be no need for the autoload mechanism.  Or am I missing something?

Bob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]