bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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 3:54 PM Andrea Corallo <akrl@sdf.org> wrote:
>>>
>>> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
>>> text editors" <bug-gnu-emacs@gnu.org> writes:
>>>
>>>
>>> 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"))
>>
>> Okay, and that would return nil if it's not native compiled, which
>> would be their cue to native compile it, yes?
>
> Yes `comp-lookup-eln' will return nil if the eln is not found.
>
>> That's nice to be able
>> to force load it.
>>
>> Without doing the modification date stuff you mentioned or purge
>> before byte compile, native compilation ends up having to be a concern
>> of anything that's doing byte compiling, which is unfortunate.
>
> Say anything that's doing byte compiling deliberately capturing
> environment values yes.
>
>   Andrea

I've reintroduced the file timestamp check on the eln files being loaded
with 79b8b6ca45.  This should protect us from loading stale eln that
captured some stale env during compilation.

I'm Ccing Andrew and this was previously discussed in bug#43532, (note
now .el and .eln timestamps can now be equal so it should work also for
the discussed case in bug#43532).

Please let us know if this change is problematic.

Thanks

  Andrea