--- Begin Message ---
|
Subject: |
28.0.50; [feature/native-comp] Recent change to native-compile-async |
|
Date: |
Mon, 23 Nov 2020 14:39:01 +1000 |
Hi,
The change to the treatment of the load parameter of
native-compile-async in commit 6781cd67 has exposed some problems with
how native compilation has been handled by the `straight.el` package
manager.
Straight calls `(native-compile-async path-to-pkg 'recursively 'late)`
to trigger compilation of packages, and relies on
`comp-deferred-compilation-black-list` to prevent compilation of
packages when requested by the user.
The reasoning behind using the late is two-fold:
1) When compilation is requested, the package has not been loaded.
Once async compilation has finished, it may have been loaded. We want
to load the native elisp if the package has been loaded, but otherwise
not force the package to load.
It seems that `late` loading provided this behaviour thanks to
`comp--late-register-subr` checking `comp-deferred-pending-h` before
loading the native definition. The hash entry will be missing for
packages where we requested compilation but were never loaded.
Relying on undocumented behaviour of the `late` flag like is obviously
fragile and naughty, but I believe this is a valid use-case. What do
you think about adding official support for this kind of "lazy"
loading?
2) The `comp-deferred-compilation-black-list` is the only way that a
user can prevent compilation of an elisp file, and this blacklist is
only checked when compilation is requested with `late` loading.
While what straight.el (and now package.el) are doing is not
technically "deferred" compilation, I think it's useful to have a
single blacklist to prevent compilation of a file regardless of how
that compilation is requested.
Thanks & Cheers,
Andrew
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#44813: 28.0.50; [feature/native-comp] Recent change to native-compile-async |
|
Date: |
Tue, 24 Nov 2020 08:25:28 +0000 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Andrew Whatson <whatson@gmail.com> writes:
> Andrea Corallo <akrl@sdf.org> wrote:
>
>> Should be inplemented as discussed as of 7a8370ed0f.
>>
>> Please have a try and see if works for you.
>
> Hi Andrea,
>
> Everything is working as expected. Thanks for the fix and for all
> your efforts on this awesome feature!
Wonderful, closing then.
Thanks for the kind words :)
Andrea
--- End Message ---