bug#44676: [PATCH] Support native compilation of packages on install

[Andrea Corallo]

Stefan Kangas <stefan@marxist.se> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>>> BTW, what is the purpose of the LOAD parameter here?
>>
>> The main purpose of that parameter is to serve deferred compilation.
>
> Thanks for the explanation, that clarifies things.
>
> This gets me thinking, could we change the LOAD parameter to be called
> LATE instead with valid values nil or non-nil?  Or is there a specific
> reason why one would want to use LOAD set to t instead of just, say:

That depends if we want to remove the normal load as an option.

>     (native-compile-async "foo.el")
>     (load "foo.el")

The issue is that this does a different thing, if foo.el was never byte
compiled you will endup with only the non compiled (nor byte or native)
definitions as the load happes before the async compilation has finished.

I understand and share your motivation of simplifying the interface,
OTOH I think for the user might be handy to say compile and load when
finished without having to rely on the comp-async hooks.

> Maybe the above example is a bit contrived, but I'm mostly trying to
> understand if we have an opportunity to simplify the interface.
>
> Oh, and come to think of it, could we just rename "late" load to
> something more descriptive (for example "after-bytecode") or would that
> be tremendously ugly?  :-)

I'd prefer to keep it as late.  Late load is a mechanism that is not
strictly related to bytecode (even if now we issue it in relation to
that) and in the code is referred as late-load in multiple palces I
believe.  Also late is shorter than after-bytecode :)

>> I think is simpler, we should from package just issue the compilation
>> without any kind of 'load'.  Then around comp.el:3528 instead of
>> complaining in case of a compilation with late load issued on a file
>> with no load property just fixup the missing the late load in
>> `comp-files-queue'.
>>
>> This will cover the case where package ask for the compilation but
>> before is completed the user load the elc and deferred compilation issue
>> another compilation with late load.
>
> OK, thanks.  Please see my patches below.
>
>> When we want to replace bytecode function definitions we perform this
>> special kind of load that I called 'late'.  During this load instead of
>> executing all top level forms of the original files we execute only
>> function definitions (paying attention to have these effective only if
>> the bytecode definition was not changed in the meanwhile).
>>
>> We should probably make this paramenter private (as for the syncronous
>> variant `native-compile') as should be really for internal use only,
>> WDYT?
>
> Yes, that sounds very reasonable.  See the fourth patch below.
>

Following up with patch comments.

Thanks

  Andrea