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

[Björn Bidar]

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?
The package has different subpackages build from 100% the same source.
The configuration is only different when it comes to ui support.