Re: MinGW build on master broken by Gnulib update

[Bruno Haible <bruno@clisp.org>]

Replying to the thread that started at
<https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00131.html>.

I agree with everything that Paul wrote in this thread, except for the
typo where we wrote "MSVC port of Emacs" but meant "mingw port of Emacs".

Eli Zaretskii replied to Paul Eggert:
> > ... Callers shouldn't do 
> > that. They are supposed to include <signal.h> to declare sig2str. 
> > sig2str.h is for something else: it's for defining SIGNUM_BOUND, and it 
> > includes signal.h only to be backwards-compatible with older Gnulib 
> > versions.
> 
> Then document this and be done.  I don't see how is this a big
> problem.

We already document this, in the module description of the 'sig2str' module:

  Include:
  <signal.h>
  "sig2str.h" /* for SIGNUM_BOUND */

It is a bit terse, but it means:
  - Callers should use '#include <signal.h>' for the general part.
  - Callers should additionally use '#include "sig2str.h"' if they need the
    SIGNUM_BOUND macro.

> > >> Instead, how about adjusting Emacs's MinGW shims to supply the missing
> > >> declarations? Something like the attached patch, say. (I don't use MinGW
> > >> so can't easily test this.)
> > > 
> > > This might solve the Emacs problem (and is not very clean even in that
> > > case), but will not help other projects that use Gnulib.
> > 
> > That's not something we need to worry about.
> 
> That is strange to hear, since Gnulib is supposed to care about all
> GNU projects, not just about Emacs.

Gnulib cares about all GNU packages. Emacs is one of them, which is why
we are discussing here. You are arguing that there are or might be other
GNU packages that have the same problem as Emacs. This is not the case.
Emacs uses the --avoid option far more extensively than other packages
that use Gnulib. And when a packages uses the --avoid option, the documentation
<https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html>
says:

  "If you want to cut a dependency, i.e., not add a module although one
   of your requested modules depends on it, you may use the option
   ‘--avoid=module’ to do so. Multiple uses of this option are possible.
   Of course, you will then need to implement the same interface as the
   removed module."

The patch that Paul suggested in
<https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00169.html>
is exactly the right thing: Since you decided that you don't want the
signal-h module, but sig2str needs this module for providing the declaration
of the two functions, you need to provide the declaration of these two
functions elsewhere.

> I have neither time nor energy for this Gnulib politics, so I went
> ahead and installed a workaround for this.  (If I had more free time,
> which I don't, I'd stopped using the Gnulib sig2str.c altogether to
> avoid the issue in the first place, but things being as they are, I
> installed an easier cop-out.)  If the Gnulib folks (CC'ed) are ready
> to reconsider, I will be happy to remove the workaround.

Adapting Gnulib to one's package can be done in multiple ways:
  - through the --avoid option for selected modules,
  - through the --local-dir option and *.diff files, which is
    roughly equivalent to applying patches after running gnulib-tool,
  - by upstreaming specific requirements to Gnulib.

Among these possibilities, use of the --local-dir option has the highest
maintenance cost, especially for a file such as signal.in.h. It would
break several times a year. Patching a rarely-modified file such as
sig2str.h, like you did, is going to work for some time, but will break
when on the Gnulib side we decide to add more declarations to this .h file.

In other words, adapting Gnulib to one's package is an art; it's a series
of continuing compromises with maintainability in mind. Paul Eggert masters
this art perfectly. You can 100% trust him in these matters.

Bruno