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

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

[Philipp Stephani]

The release archive for Emacs 27.1 as distributed on ftp.gnu.org is
missing the emacs-module.h header.  The header is present in the Emacs
26.3 release archive.  Let's please make sure that the header is
consistently present in the release archives.


In GNU Emacs 27.1.50 (build 28, x86_64-pc-linux-gnu, GTK+ Version 3.24.22)
 of 2020-11-29
Repository revision: 17fa17be3d93fc10f6ca91d738d5056b1b9f1f1e
Repository branch: emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux rodete

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --enable-checking=all --enable-gtk-deprecation-warnings
 --enable-gcc-warnings=warn-only --enable-check-lisp-object-type
 --with-mailutils --without-pop 'CFLAGS=-O0 -g3' LDFLAGS=-g3'

Configured features:
XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS FREETYPE HARFBUZZ XFT ZLIB TOOLKIT_SCROLL_BARS GTK3
X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER GMP

Important settings:
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec epa epg epg-config gnus-util
rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst skeleton
derived edmacro kmacro pcase ffap thingatpt url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars mailcap subr-x rx gnutls puny seq
byte-opt gv bytecomp byte-compile cconv dbus xml compile comint
ansi-color ring cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 68118 7094)
 (symbols 48 8597 1)
 (strings 32 23696 1941)
 (string-bytes 1 767387)
 (vectors 16 13054)
 (vector-slots 8 169386 8176)
 (floats 8 25 28)
 (intervals 56 208 0)
 (buffers 1000 12))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich.  Falls Sie diese fälschlicherweise erhalten haben
sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie
alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail
an die falsche Person gesendet wurde.

This e-mail is confidential.  If you received this communication by mistake,
please don’t forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

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

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 02 Dec 2020 18:52:26 +0100
> 
> The release archive for Emacs 27.1 as distributed on ftp.gnu.org is
> missing the emacs-module.h header.

This happens because emacs-module.h was removed from make-dist, in
this commit:

  commit 1043cd30acffcc0b61da4a80dcf3f8a5ac459267
  Author:     Paul Eggert <eggert@cs.ucla.edu>
  AuthorDate: Sat Jun 8 14:08:05 2019 -0700
  Commit:     Paul Eggert <eggert@cs.ucla.edu>
  CommitDate: Sat Jun 8 14:42:10 2019 -0700

      Fix out-of-source make-dist problems

      Problem with jisx2131-filter reported by Phillip Lord in:
      https://lists.gnu.org/r/emacs-devel/2019-06/msg00147.html
      * admin/charsets/Makefile.in (SED_SCRIPT):
      Put it in $(srcdir), which is not necessarily the working directory.
      ($(SED_SCRIPT)): Rename from jisx2131-filter.  All uses changed.
      (clean): Do not remove SED_SCRIPT.
      (extraclean): Remove it here instead.
      * make-dist (possibly_non_vc_files): Remove src/emacs-module.h.
      Although it is portable and could be distributed in the tarball,
      it's too much hassle to do that, so let each builder make it.

Wasn't there some discussion about the problems with distributing it,
as it is not entirely portable?

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

[Philipp Stephani]

Am Mi., 2. Dez. 2020 um 19:10 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Wed, 02 Dec 2020 18:52:26 +0100
> >
> > The release archive for Emacs 27.1 as distributed on ftp.gnu.org is
> > missing the emacs-module.h header.
>
> This happens because emacs-module.h was removed from make-dist, in
> this commit:
>
>   commit 1043cd30acffcc0b61da4a80dcf3f8a5ac459267
>   Author:     Paul Eggert <eggert@cs.ucla.edu>
>   AuthorDate: Sat Jun 8 14:08:05 2019 -0700
>   Commit:     Paul Eggert <eggert@cs.ucla.edu>
>   CommitDate: Sat Jun 8 14:42:10 2019 -0700
>
>       Fix out-of-source make-dist problems
>
>       Problem with jisx2131-filter reported by Phillip Lord in:
>       https://lists.gnu.org/r/emacs-devel/2019-06/msg00147.html
>       * admin/charsets/Makefile.in (SED_SCRIPT):
>       Put it in $(srcdir), which is not necessarily the working directory.
>       ($(SED_SCRIPT)): Rename from jisx2131-filter.  All uses changed.
>       (clean): Do not remove SED_SCRIPT.
>       (extraclean): Remove it here instead.
>       * make-dist (possibly_non_vc_files): Remove src/emacs-module.h.
>       Although it is portable and could be distributed in the tarball,
>       it's too much hassle to do that, so let each builder make it.
>
> Wasn't there some discussion about the problems with distributing it,
> as it is not entirely portable?

If so, then we need to fix that. emacs-module.h must be 100% portable.

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

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 2 Dec 2020 19:11:44 +0100
> Cc: 45012@debbugs.gnu.org
> 
> >   commit 1043cd30acffcc0b61da4a80dcf3f8a5ac459267
> >   Author:     Paul Eggert <eggert@cs.ucla.edu>
> >   AuthorDate: Sat Jun 8 14:08:05 2019 -0700
> >   Commit:     Paul Eggert <eggert@cs.ucla.edu>
> >   CommitDate: Sat Jun 8 14:42:10 2019 -0700
> >
> >       Fix out-of-source make-dist problems
> >
> >       Problem with jisx2131-filter reported by Phillip Lord in:
> >       https://lists.gnu.org/r/emacs-devel/2019-06/msg00147.html
> >       * admin/charsets/Makefile.in (SED_SCRIPT):
> >       Put it in $(srcdir), which is not necessarily the working directory.
> >       ($(SED_SCRIPT)): Rename from jisx2131-filter.  All uses changed.
> >       (clean): Do not remove SED_SCRIPT.
> >       (extraclean): Remove it here instead.
> >       * make-dist (possibly_non_vc_files): Remove src/emacs-module.h.
> >       Although it is portable and could be distributed in the tarball,
> >       it's too much hassle to do that, so let each builder make it.
> >
> > Wasn't there some discussion about the problems with distributing it,
> > as it is not entirely portable?
> 
> If so, then we need to fix that. emacs-module.h must be 100% portable.

Why is it a problem that emacs-module.h is built as part of Emacs?

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

[Philipp Stephani]

Am Mi., 2. Dez. 2020 um 19:33 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Wed, 2 Dec 2020 19:11:44 +0100
> > Cc: 45012@debbugs.gnu.org
> >
> > >   commit 1043cd30acffcc0b61da4a80dcf3f8a5ac459267
> > >   Author:     Paul Eggert <eggert@cs.ucla.edu>
> > >   AuthorDate: Sat Jun 8 14:08:05 2019 -0700
> > >   Commit:     Paul Eggert <eggert@cs.ucla.edu>
> > >   CommitDate: Sat Jun 8 14:42:10 2019 -0700
> > >
> > >       Fix out-of-source make-dist problems
> > >
> > >       Problem with jisx2131-filter reported by Phillip Lord in:
> > >       https://lists.gnu.org/r/emacs-devel/2019-06/msg00147.html
> > >       * admin/charsets/Makefile.in (SED_SCRIPT):
> > >       Put it in $(srcdir), which is not necessarily the working directory.
> > >       ($(SED_SCRIPT)): Rename from jisx2131-filter.  All uses changed.
> > >       (clean): Do not remove SED_SCRIPT.
> > >       (extraclean): Remove it here instead.
> > >       * make-dist (possibly_non_vc_files): Remove src/emacs-module.h.
> > >       Although it is portable and could be distributed in the tarball,
> > >       it's too much hassle to do that, so let each builder make it.
> > >
> > > Wasn't there some discussion about the problems with distributing it,
> > > as it is not entirely portable?
> >
> > If so, then we need to fix that. emacs-module.h must be 100% portable.
>
> Why is it a problem that emacs-module.h is built as part of Emacs?

How is that related? emacs-module.h is just a textual concatenation of
various fragments. There's nothing platform-specific that's part of
its build process.
A module author shouldn't need to care about whether emacs-module.h is
checked in or created by configure; it should just be part of the
release.

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

[Eli Zaretskii]

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

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.

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

[Eli Zaretskii]

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

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

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

[Philipp Stephani]

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.

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

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 12 Dec 2020 15:55:46 +0100
> Cc: 45012@debbugs.gnu.org
> 
> > > 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.

There's no need to build Emacs, you only need to configure it to get
emacs-module.h generated.

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

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 12 Dec 2020 15:55:46 +0100
> Cc: 45012@debbugs.gnu.org
> 
> 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.

Emacs is not the only package that needs to be built to have the
header files needed to build software against it.  Many libraries put
their users through the same "hassles", so it isn't like Emacs is the
odd one out here.

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

[Philipp Stephani]

Am Sa., 12. Dez. 2020 um 19:37 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 12 Dec 2020 15:55:46 +0100
> > Cc: 45012@debbugs.gnu.org
> >
> > > > 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.
>
> There's no need to build Emacs, you only need to configure it to get
> emacs-module.h generated.

Yes, but in practice running configure is more complex than compiling:
compiling only needs a C compiler and a linker, while running
configure also needs a shell and (potentially) other programs like
pkg-config. So not having to run the compile step doesn't help much
here.

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

[Philipp Stephani]

Am Sa., 12. Dez. 2020 um 19:57 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 12 Dec 2020 15:55:46 +0100
> > Cc: 45012@debbugs.gnu.org
> >
> > 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.
>
> Emacs is not the only package that needs to be built to have the
> header files needed to build software against it.  Many libraries put
> their users through the same "hassles", so it isn't like Emacs is the
> odd one out here.

True, but I'm still wondering why it's a bigger hassle to generate
emacs-module.h than to build the .elc files.

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

[Stefan Kangas]

Philipp Stephani <p.stephani2@gmail.com> writes:

> Am Mi., 2. Dez. 2020 um 19:10 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>>
>> > From: Philipp Stephani <p.stephani2@gmail.com>
>> > Date: Wed, 02 Dec 2020 18:52:26 +0100
>> >
>> > The release archive for Emacs 27.1 as distributed on ftp.gnu.org is
>> > missing the emacs-module.h header.
>>
>> This happens because emacs-module.h was removed from make-dist, in
>> this commit:
>>
>>   commit 1043cd30acffcc0b61da4a80dcf3f8a5ac459267
>>   Author:     Paul Eggert <eggert@cs.ucla.edu>
>>   AuthorDate: Sat Jun 8 14:08:05 2019 -0700
>>   Commit:     Paul Eggert <eggert@cs.ucla.edu>
>>   CommitDate: Sat Jun 8 14:42:10 2019 -0700
>>
>>       Fix out-of-source make-dist problems
>>
>>       Problem with jisx2131-filter reported by Phillip Lord in:
>>       https://lists.gnu.org/r/emacs-devel/2019-06/msg00147.html
>>       * admin/charsets/Makefile.in (SED_SCRIPT):
>>       Put it in $(srcdir), which is not necessarily the working directory.
>>       ($(SED_SCRIPT)): Rename from jisx2131-filter.  All uses changed.
>>       (clean): Do not remove SED_SCRIPT.
>>       (extraclean): Remove it here instead.
>>       * make-dist (possibly_non_vc_files): Remove src/emacs-module.h.
>>       Although it is portable and could be distributed in the tarball,
>>       it's too much hassle to do that, so let each builder make it.
>>
>> Wasn't there some discussion about the problems with distributing it,
>> as it is not entirely portable?
>
> If so, then we need to fix that. emacs-module.h must be 100% portable.

Paul, do you have any opinion here?  The discussion shows that Eli
thought at the time that it's not really worth doing much about this.

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

[Paul Eggert]

On 10/11/21 5:36 AM, Stefan Kangas wrote:
>> If so, then we need to fix that. emacs-module.h must be 100% portable.

> Paul, do you have any opinion here?  The discussion shows that Eli
> thought at the time that it's not really worth doing much about this.

It's not a problem I thought worth addressing either. That being said, 
it would be nice if someone had the time to code up a fix, as that'd 
make Phillipp Stephani's builds go faster. Any fix should continue to 
address the out-of-source 'make dist' problem that Phillip Lord reported 
a couple of years ago 
<https://lists.gnu.org/r/emacs-devel/2019-06/msg00147.html>.