unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrea Corallo <akrl@sdf.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 56743@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#56743: 29.0.50; Sharing .eln files beween different builds
Date: Mon, 25 Jul 2022 19:57:48 +0000	[thread overview]
Message-ID: <xjfwnc1kls3.fsf@ma.sdf.org> (raw)
In-Reply-To: <834jz5fo4e.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 25 Jul 2022 14:06:09 +0300")

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





  reply	other threads:[~2022-07-25 19:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2022-07-26 11:48     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xjfwnc1kls3.fsf@ma.sdf.org \
    --to=akrl@sdf.org \
    --cc=56743@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).