GNU bug report logs - #45012
27.1.50; Emacs 27.1 release archive missing emacs-module.h

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 45012 <at> debbugs.gnu.org
Subject: bug#45012: 27.1.50; Emacs 27.1 release archive missing emacs-module.h
Date: Sun, 06 Dec 2020 21:12:18 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sun, 6 Dec 2020 18:13:30 +0100
> Cc: 45012 <at> debbugs.gnu.org
> 
> > I'm making a step back and asking why you thought it was a problem
> > that emacs-module.h was not part of the release tarball.  It gets
> > built as part of Emacs, so once Emacs is built, the header is
> > available.  So why do you want it to be in the tarball?
> 
> Concretely, I'm using emacs-module.h for my Go bindings to the module
> API (https://godoc.org/github.com/phst/emacs). The compilation of the
> library naturally requires emacs-module.h, but not Emacs.

So you will build the module, but never test it or use it?  Is that a
reasonably practical use case?

> Somewhat more abstractly, Emacs modules are independent from Emacs,
> and Emacs isn't needed (and shouldn't be needed) to build them.

If you just build a module and never use it, perhaps.  Once you want
to use it, you need Emacs.

> Moreover, the build process for Emacs is rather involved, requiring
> multiple steps lots of external binaries such as the GNU Autotools,
> etc., while building a module only requires a C compiler (or compiler
> for whatever language the module is written in) and a linker that
> produces shared objects.

Most people nowadays don't build their Emacs, they get it from a
distribution.  That distribution will (or should) provide
emacs-module.h as well.

So I'm still not sure we have a good reason to revert the decision we
made for Emacs 27 regarding emacs-module.h exclusion.

Previous Next

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