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, 26 Jun 2023 03:14:17 +0300
>>>> 
>>>> I'm building Emacs master for OpenSUSE to provide testing.
>>>> OpenSUSE packaging packages Emacs so that they have three builds with
>>>> different feature sets: X11 without GTK, GTK and one build just without
>>>> X11 or GTK.
>>>> 
>>>> This helps different users to chose their preferred builds and keeps
>>>> build workers small for Emacs packages build.
>>>> 
>>>> The packages share the elisp, native-lisp ahead of time compilations and
>>>> docs.
>>>> 
>>>> Recently the native-lisp load path changed to change per Emacs
>>>> executable.
>>>
>>> It isn't a recent change, at least not in principle.
>>
>> What could have change this?
>>
>>>> I don't know the exact commit when this changed but it was
>>>> between ref 3c8167ec0f9647e6fc33e65b0a0324f96cb795ee and
>>>> d46a2fa319808963bbe8d3a90e7dbb13fcd844f5.
>>>> 
>>>> Now my questions: Is this a bug or can a different hash be used to
>>>> determine the system load-path? It is very useful to precompile the
>>>> lisp code once per emacs builds that share the same code.
>>>
>>> It's impossible to share native-compiled *.eln files between different
>>> builds, because they depend on the primitives compiled into the build
>>> and on the architecture of the host CPU.
>>
>>> So you must have a separate directory for each build configuration,
>>> and any significant change in the Emacs C code will require
>>> recompilation of all the *.eln files.
>>
>> Each build configuration is 100% the same except the optional
>> dependencies they are build with.
>>
>> There's no change to any source they are build one after the other.
>>
>> See the spec file here:
>> https://build.opensuse.org/package/view_file/home:Thaodan:emacs/emacs/emacs.spec?expand=1
>
> The hash depends on the set of C primitives present in Emacs.  If the
> hash differs it means your configurations are producing Emacsen with
> different sets of primitives, and this makes eln files incompatible.

OK but so why did work with the commit
3c8167ec0f9647e6fc33e65b0a0324f96cb795ee and before?

Nothing has changed in the build environment except the commits between
good commit and d46a2fa319808963bbe8d3a90e7dbb13fcd844f5 or later.