Re: Sharing native-lisp system load-path between builds

[Björn Bidar]

Andrea Corallo <acorallo@gnu.org> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>>>> Date: Mon, 14 Aug 2023 21:29:34 +0300
>>>> 
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>> 
>>>> > Thanks.  So what does "work" and "does not work" mean in this context?
>>>> 
>>>> Work means the eln files could be shared, doesn't mean the files can't
>>>> be shared the hash in the native lisp path is different and the files
>>>> are no longer compatible.
>>>
>>> How did you share them? did you manually copy them into the same
>>> directory or forced Emacs to write them there?  Or did Emacs create
>>> *.eln files with the same hashes and in the same 29.0.50-NNNNN
>>> subdirectory?
>> Yes exactly. The <version>-<hash> directory was the same.
>>
>>> Also, which *.el files were compiled into *.eln files
>>> you could share -- were those the preloaded *.el files, non-preloaded
>>> *.el files from the Emacs tree, or third-party *.el files from
>>> packages that are not bundled with Emacs?
>> Only the builtin el files as can be seen in the spec file.
>>
>>>In general, such different configurations could only be able to share
>>>*.eln files by sheer luck.  It is enough to have one more or one less
>>>primitive in one of the builds to require a separate set of *.eln
>>>files, because the hash of the versioned subdirectory of native-lisp/
>>>and of eln-cache changes when primitives are added or deleted.  That
>>>has been so for a very long time, definitely long before commit
>>>3c8167ec0f964.
>>
>> Does enabling or disabling lets say png change any of those
>> primitives?
>
> Yes

What changed that now these primitives change this way or is this simply
a side effect of another change?