emacs-libvterm icon indicating copy to clipboard operation
emacs-libvterm copied to clipboard

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

Open manphiz opened this issue 1 year ago • 6 comments

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?

manphiz avatar Mar 18 '24 07:03 manphiz

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

Sbozzolo avatar May 20 '24 02:05 Sbozzolo

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

manphiz avatar May 21 '24 19:05 manphiz

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.

Sbozzolo avatar Jun 01 '24 17:06 Sbozzolo

Just opened PR #735 as an attempt. PTAL.

manphiz avatar Sep 10 '24 10:09 manphiz

Friendly ping for https://github.com/akermu/emacs-libvterm/pull/735, which adds an option in CMake to prefer emacs-module.h from an Emacs installation over the vendored version.

manphiz avatar Oct 02 '24 18:10 manphiz