bug#45012: 27.1.50; Emacs 27.1 release archive missing emacs-module.h

[Philipp Stephani]

Am Mi., 2. Dez. 2020 um 19:53 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Wed, 2 Dec 2020 19:47:49 +0100
> > Cc: 45012@debbugs.gnu.org
> >
> > > Why is it a problem that emacs-module.h is built as part of Emacs?
> >
> > How is that related?
>
> 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. In the build
process I therefore extract only emacs-module.h from the release
archive 
(https://github.com/phst/emacs/blob/29d32c83d5d39b1f0ac41bb79372ee7e1cb7439d/header.BUILD#L17).
That works with Emacs 26.3, but not with 27.1.
Somewhat more abstractly, Emacs modules are independent from Emacs,
and Emacs isn't needed (and shouldn't be needed) to build them.
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. Therefore it's reasonable to assume that
module authors shouldn't need to build Emacs (or aren't even able to
build Emacs). Including emacs-module.h in the release archive achieves
that.