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

[Andrea Corallo <acorallo@gnu.org>]

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

  Andrea