bug#44813: 28.0.50; [feature/native-comp] Recent change to native-compile-async

[Andrew Whatson]

Andrea Corallo <akrl@sdf.org> wrote:
>
> I think straight should call `async-native-compile' with the load
> parameter set to nil and perform the conventional byte compilation.
>
> In case the late load will prove to be necessary (bytecode is loaded
> before native compilation has finished) should be set automatically by
> the existent machinery.

Ok great, that is much easier.

> I think would be nicer to add like a selector parameter to
> `async-native-compile', this being a regexp to be satisfied for
> compilation.
>
> The reason why we rely on `comp-deferred-compilation-black-list' for
> deferred compilation is that the user indeed does not invoke a function
> as this happen automatically.
>
> So the proposal would be to have like:
>
> `(defun native-compile-async (paths &optional recursively load selector)`
>
> WDYT?

Most users will be running with `comp-deferred-compilation` enabled,
even when using a package manager that pre-compiles their packages.
Using a selector to exclude files from the pre-compilation step won't
prevent them from being compiled later with deferred loading.
Straight has a `no-native-compile` option for package recipes to
explicitly prevent their compilation, and the deferred compilation
blacklist is the only way we can ensure this behaviour.  It's also
possible that a user has added their own entries to the blacklist and
would expect straight to respect those entries when compiling
packages.

I agree that the selector is an improvement to the recursive
compilation API, but in straight's case we would just use a selector
which checked against `comp-deferred-compilation-black-list`.  This
solution would still allow people to call `native-compile-async`
directly to bypass the blacklist, which might be desirable.  If you're
happy with this outcome, I think it's acceptable.

Thanks!