* bug#56743: 29.0.50; Sharing .eln files beween different builds
@ 2022-07-24 15:58 Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-24 16:21 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-24 15:58 UTC (permalink / raw)
To: 56743
Package: Emacs
Version: 29.0.50
It would be good to try and make sure the `.eln` files can be shared
between different builds of the release tarballs (ie. the exact same
source code, just configured differently). This would be beneficial for
example for distributions like Debian which offer `emacs-nox`,
`emacs-gtk`, and emacs-lucid` variants, which could then share the
`.eln` files.
Obviously, we can't share them between all the different combinations of
build options (e.g. `wide-int` and `non-wide-int`) but it shouldn't be
too hard to make sure they can be shared for many/most other choices, IIUC.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#56743: 29.0.50; Sharing .eln files beween different builds
2022-07-24 15:58 bug#56743: 29.0.50; Sharing .eln files beween different builds Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-24 16:21 ` Eli Zaretskii
2022-07-24 17:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-07-24 16:21 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 56743
> Date: Sun, 24 Jul 2022 11:58:22 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> It would be good to try and make sure the `.eln` files can be shared
> between different builds of the release tarballs (ie. the exact same
> source code, just configured differently). This would be beneficial for
> example for distributions like Debian which offer `emacs-nox`,
> `emacs-gtk`, and emacs-lucid` variants, which could then share the
> `.eln` files.
You want to remove the dependence of .eln files on the primitives that
are implemented in C?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#56743: 29.0.50; Sharing .eln files beween different builds
2022-07-24 16:21 ` Eli Zaretskii
@ 2022-07-24 17:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-25 11:06 ` Eli Zaretskii
2022-07-26 11:48 ` Lars Ingebrigtsen
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-24 17:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 56743
>> It would be good to try and make sure the `.eln` files can be shared
>> between different builds of the release tarballs (ie. the exact same
>> source code, just configured differently). This would be beneficial for
>> example for distributions like Debian which offer `emacs-nox`,
>> `emacs-gtk`, and emacs-lucid` variants, which could then share the
>> `.eln` files.
>
> You want to remove the dependence of .eln files on the primitives that
> are implemented in C?
No, just make sure the hash used to find the `.eln` doesn't depend
whether the build is made with Lucid or Gtk or something else.
IIUC this mostly means that all the Gtk/Lucid/X11-specific
functions&variables exported to ELisp will need to be exported in all
the builds (probably with dummy definitions).
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#56743: 29.0.50; Sharing .eln files beween different builds
2022-07-24 17:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-25 11:06 ` Eli Zaretskii
2022-07-25 19:57 ` Andrea Corallo
2022-07-26 11:48 ` Lars Ingebrigtsen
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-07-25 11:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 56743
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 56743@debbugs.gnu.org
> Date: Sun, 24 Jul 2022 13:49:42 -0400
>
> >> It would be good to try and make sure the `.eln` files can be shared
> >> between different builds of the release tarballs (ie. the exact same
> >> source code, just configured differently). This would be beneficial for
> >> example for distributions like Debian which offer `emacs-nox`,
> >> `emacs-gtk`, and emacs-lucid` variants, which could then share the
> >> `.eln` files.
> >
> > You want to remove the dependence of .eln files on the primitives that
> > are implemented in C?
>
> No, just make sure the hash used to find the `.eln` doesn't depend
> whether the build is made with Lucid or Gtk or something else.
AFAIU, if the set of the primitives is identical in the builds, the
*.eln files should be compatible. But I think there are primitives in
some of these builds that don't exist in others; thus my question.
> IIUC this mostly means that all the Gtk/Lucid/X11-specific
> functions&variables exported to ELisp will need to be exported in all
> the builds (probably with dummy definitions).
Even if this makes sense (and I'm not sure it does), this is a lot of
work for very little gain.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#56743: 29.0.50; Sharing .eln files beween different builds
2022-07-25 11:06 ` Eli Zaretskii
@ 2022-07-25 19:57 ` Andrea Corallo
0 siblings, 0 replies; 6+ messages in thread
From: Andrea Corallo @ 2022-07-25 19:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 56743, Stefan Monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: 56743@debbugs.gnu.org
>> Date: Sun, 24 Jul 2022 13:49:42 -0400
>>
>> >> It would be good to try and make sure the `.eln` files can be shared
>> >> between different builds of the release tarballs (ie. the exact same
>> >> source code, just configured differently). This would be beneficial for
>> >> example for distributions like Debian which offer `emacs-nox`,
>> >> `emacs-gtk`, and emacs-lucid` variants, which could then share the
>> >> `.eln` files.
>> >
>> > You want to remove the dependence of .eln files on the primitives that
>> > are implemented in C?
>>
>> No, just make sure the hash used to find the `.eln` doesn't depend
>> whether the build is made with Lucid or Gtk or something else.
>
> AFAIU, if the set of the primitives is identical in the builds, the
> *.eln files should be compatible. But I think there are primitives in
> some of these builds that don't exist in others; thus my question.
That's correct. IIUC this is what Stefan meant as well.
>> IIUC this mostly means that all the Gtk/Lucid/X11-specific
>> functions&variables exported to ELisp will need to be exported in all
>> the builds (probably with dummy definitions).
>
> Even if this makes sense (and I'm not sure it does), this is a lot of
> work for very little gain.
Other than the work to go there the maintenance might not be trivial, and
elns most likely would be still not compatible between Emacs versions.
That said I can't comment on the trade off.
Andrea
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#56743: 29.0.50; Sharing .eln files beween different builds
2022-07-24 17:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-25 11:06 ` Eli Zaretskii
@ 2022-07-26 11:48 ` Lars Ingebrigtsen
1 sibling, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-26 11:48 UTC (permalink / raw)
To: 56743; +Cc: eliz, monnier
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:
> IIUC this mostly means that all the Gtk/Lucid/X11-specific
> functions&variables exported to ELisp will need to be exported in all
> the builds (probably with dummy definitions).
I think that's an interesting idea. Currently, there's this odd
difference between C- and Lisp-defined functions/variables, where
Lisp-defined ones are always available, even if the Emacs build doesn't
support the feature, and the C ones aren't.
So it makes sense conceptually to move the DEFUN/DEFVARs outside the
#ifdefs (but stub out the innards). However, I think that'll lead to a
lot of regressions in code out there -- it's super common (and
recommended practice) to check whether a C level function is fboundp as
a signal that it works, and making these functions always available
would break that.
So I don't think this is a feasible direction to go in.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-07-26 11:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-24 15:58 bug#56743: 29.0.50; Sharing .eln files beween different builds Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-24 16:21 ` Eli Zaretskii
2022-07-24 17:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-25 11:06 ` Eli Zaretskii
2022-07-25 19:57 ` Andrea Corallo
2022-07-26 11:48 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).