GNU bug report logs - #56743
29.0.50; Sharing .eln files beween different builds

Previous Next

To reply to this bug, email your comments to 56743 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Sharing .eln files beween different builds
Date: Sun, 24 Jul 2022 11:58:22 -0400

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

Message #8 received at 56743 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56743 <at> debbugs.gnu.org
Subject: Re: bug#56743: 29.0.50; Sharing .eln files beween different builds
Date: Sun, 24 Jul 2022 19:21:01 +0300

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

Message #11 received at 56743 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56743 <at> debbugs.gnu.org
Subject: Re: bug#56743: 29.0.50; Sharing .eln files beween different builds
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.

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

Message #14 received at 56743 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56743 <at> debbugs.gnu.org
Subject: Re: bug#56743: 29.0.50; Sharing .eln files beween different builds
Date: Mon, 25 Jul 2022 14:06:09 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 56743 <at> 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.

Message #17 received at 56743 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56743 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56743: 29.0.50; Sharing .eln files beween different builds
Date: Mon, 25 Jul 2022 19:57:48 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: 56743 <at> 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

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56743 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56743: 29.0.50; Sharing .eln files beween different builds
Date: Tue, 26 Jul 2022 13:48:01 +0200

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.