search

akermu / emacs-libvterm

Emacs libvterm integration
GNU General Public License v3.0
1.69k stars 135 forks source link

Old emacs-module.h vs using one from an Emacs installation #709

Open manphiz opened 5 months ago

manphiz commented 5 months ago

It looks like emacs-module.h was copied from the Emacs source tree 6 years ago. I wonder whether this file was kept from being updated so as to be compatible with older Emacs versions?

Meanwhile, is it desirable to let emacs-libvterm detect an existing Emacs installation and use the emacs-module.h from that if available?

Sbozzolo commented 3 months ago

Is there anything you would like to have from more recent versions?

manphiz commented 3 months ago

Gabriele Bozzola @.***> writes:

Is there anything you would like to have from more recent versions?

Nothing in particular right now, as it seems emacs-module.h has been kept mostly forward-compatible. Here[1] is a list of changes to emacs-module.h.in in Emacs source through the years, which are not many actually. I think [2] could be the most prominent change, though different @.***_major_version@ versions may be kept of a compatible ABI layout most of the time. For now.

Anyway, my question is more about whether it is desirable to provide an option to use emacs-module.h from an existing Emacs installation so as to ensure maximum compatibility, as well as to avoid accidental breakage just in case. This may be more of interest for packaging in a Linux distribution (e.g. Debian, which is patched to use the one from its Emacs installation[3]) compared to distributing through ELPA.

[1] https://github.com/emacs-mirror/emacs/commits/master/src/emacs-module.h.in?before=ce8e292bca84f29cea540e3e23e88ec7a5d1674e+35 [2] https://github.com/emacs-mirror/emacs/commit/232a36f17e2796c52cb0b1afd5872c454b92ce62 [3] https://salsa.debian.org/emacsen-team/emacs-libvterm/-/blob/debian/master/debian/patches/use-system-emacs-module.h.patch?ref_type=heads -- Xiyue Deng

Sbozzolo commented 2 months ago

Yes, I agree.

It is immediately clear to me that we want to use the most recent emacs-module.h all the time. If the it changes signficantly (ie, in a non-backward compatible way), we would need to change our vterm-module too. Similarly, if we wanted to take advantage of newer features, we would probably have to add compatibility on our end.