[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated
From: |
Andrea Corallo |
Subject: |
bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes |
Date: |
Sun, 21 Mar 2021 20:54:04 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:
> Aaron Jensen <aaronjensen@gmail.com> writes:
>
>> On Sun, Mar 21, 2021 at 12:27 PM Andrea Corallo <akrl@sdf.org> wrote:
>>>
>>> Hi Aaron,
>>>
>>> I had to slightly modify your init.el reproducer as we have changed the
>>> semantic of `load' [1].
>>
>> With this change, how do you specify that you want the eln to load if
>> it's there? If I understand correctly, this prevents loading the eln
>> with load unless it is specified explicitly? Or can you leave the
>> extension off when loading and that will prefer the eln, then elc,
>> then el?
>
> Exactly load by default tries to add the extentions to the FILE
> argument.
>
>>> I think what happened is that in the original reproducer the second load
>>> of the .elc file still automatically loaded in place the corresponding
>>> .eln as the source file didn't changed. The issue here is that in the
>>> compilation unit repro.elk is capturing some of the environment and this
>>> is not accounted in the hash computation of the .eln file.
>>
>> The original repro simulated a restart without a restart. The real bug
>> (in straight.el) is that on start, it loads a byte compiled/native
>> compiled file that relies on outside environment. So, that may be
>> fixed now because I believe they load the elc explicitly, but that
>> means it'll never load the native compiled version. Ideally, they
>> would, but I don't know how to force loading byte compiled OR native
>> compiled in one command.
>
> ATM to force the byte-code version to be used one can use `load' making
> the .elc extension explicit (or without using the extension binding
> `load-no-native' to non-nil).
>
> To explicitly force load the native code version one has to do like:
>
> (load (comp-el-to-eln-filename ".../foo.el"))
>
> But this is limited as it works only if the .eln is in the first
> directory of `com-eln-load-path', so probably we have to offer a more
> complete solution.
Okay I've added `comp-lookup-eln' son now the user can search if a
certain .eln is in reach in `comp-eln-load-path' for a given .el.
So now one can use the following to force a native load.
(load (comp-lookup-eln ".../foo.el"))
Andrea
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Andrea Corallo, 2021/03/21
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Aaron Jensen, 2021/03/21
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Andrea Corallo, 2021/03/21
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes,
Andrea Corallo <=
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Aaron Jensen, 2021/03/21
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Andrea Corallo, 2021/03/22
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Andrea Corallo, 2021/03/26
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Aaron Jensen, 2021/03/28
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Andrea Corallo, 2021/03/29
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Aaron Jensen, 2021/03/29
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Andrea Corallo, 2021/03/31
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Aaron Jensen, 2021/03/31
- bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes, Andrea Corallo, 2021/03/31