bug#56743: 29.0.50; Sharing .eln files beween different builds

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]

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

bug#56743: 29.0.50; Sharing .eln files beween different builds

[Eli Zaretskii]

> 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?

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]

>> 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

bug#56743: 29.0.50; Sharing .eln files beween different builds

[Eli Zaretskii]

> 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.

bug#56743: 29.0.50; Sharing .eln files beween different builds

[Andrea Corallo]

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

bug#56743: 29.0.50; Sharing .eln files beween different builds

[Lars Ingebrigtsen]

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.