[Top][All Lists]

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

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

From: Andrea Corallo
Subject: bug#44676: [PATCH] Support native compilation of packages on install
Date: Wed, 18 Nov 2020 16:05:19 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Stefan Kangas <stefan@marxist.se> writes:

> Hi Andrea,
> Andrea Corallo <akrl@sdf.org> writes:
>> Late load assume the current bytecode is already loaded when the native
>> load will happen.  This because late load is designed to be issued when
>> some bytecode file is loaded and no native code alternative is found.
> Thanks, I had trouble figuring out what this parameter meant.  Maybe we
> could improve its documentation.


> BTW, what is the purpose of the LOAD parameter here?  Is it just a
> convenience feature to allow a user to load the file after compiling?
> I'm asking because that option was recently made obsolete for
> `byte-compile-file'.

The main purpose of that parameter is to serve deferred compilation.

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,

>> We should probably issue the async compilation here without late load
>> and in case the bytecode is being loaded before native compilation was
>> done just patch the kind of load stored into `comp-files-queue'.  ATM if
>> the stored load property and new one are not matching we complain (See
>> comp.el:3528).
>> So yeah non 100% straight forward :)
> So when loading a byte-compiled file, Fload should check if there exists
> an entry for this file in `comp-files-queue', and if there is one,
> change its load property to `lazy'?  Do I understand you correctly?
> Sorry if I'm not very clear, I'm still trying to understand all this.

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

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.

>> That said I think we should have a customize to decided if we want
>> package to eager command native compilation.
>> I may never used some of the installed files and prefer the current
>> solution for that, or maybe I may just like to have the compilation
>> happening in a more diluted fashion and on demand (my personal taste).
> OK, I'll add such an option.




reply via email to

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