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

[Philipp Stephani <p.stephani2@gmail.com>]

Am So., 6. Dez. 2020 um 20:12 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sun, 6 Dec 2020 18:13:30 +0100
> > Cc: 45012@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?

It depends what "you" is. "You" could be a continuous build system
that's capable of compiling C code, but not of running Emacs. That's
not far-fetched; compiling C code is far more common than running
Emacs, and therefore is better supported by build systems.
Or, the tests for the module aren't written in ELisp. It's entirely
reasonable to write the tests in the language that the module is
written in, and e.g. mock out the emacs_env object.
Or: the module provides only trivial wrappers around existing complex
functions, and those implementation functions have tests written in
another language.

>
> > 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.

See above, "you" can be non-human users that can't or don't need to
use Emacs in any meaningful way.

>
> > 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.

That only works for non-hermetic builds. Hermetic builds (such as the
Bazel builds in my example) need to ship all dependencies and can't
rely on local distributions. CI/CD systems also tend to not have a
full GNU/Linux distribution with Linux installed, or they run builds
in a sandbox that doesn't allow access to local files (for hermeticity
or security), or similar.

>
> 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.

Quoting the commit message, the only reason given for not including
emacs-module.h is "it's too much hassle", without any explanation what
this "hassle" consists in and why it is "too much". (The release
tarball also includes .elc files, and those are a much bigger hassle
to build.) Rather, this decision shifts the hassle to the users.