[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sharing native-lisp system load-path between builds, my own error
From: |
Björn Bidar |
Subject: |
Re: Sharing native-lisp system load-path between builds, my own error |
Date: |
Tue, 26 Sep 2023 17:26:29 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> Date: Sat, 19 Aug 2023 01:23:00 +0300
>>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>> >> 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?
>
> Nothing fundamental changed recently, this was always the case, since
> Emacs 28 was released. So if it worked for you until now, it was only
> by sheer luck: somehow the configurations you have been building had
> the same primitives in them, and now they don't.
>
> The assumption that you can share the *.eln files between different
> configurations was never valid.
The error was on my side. I assumed that my package only tracked on set
of eln files since without further thinking it does sound like that
compiled lisp code should be the same between 3 variants of the same
build besides different libraries linked to Emacs.
But the package contained compiled elisp for all three which worked
before commit 0cf6e0998ba. I ran distclean after each build, which
before said commit didn't delete the native-lisp directory but after it
deleted them to keeping only the last build.
After keeping each native-lisp directory again for each variant everything
is fine.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Sharing native-lisp system load-path between builds, my own error,
Björn Bidar <=