Re: MinGW build on master broken by Gnulib update

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 5 Sep 2024 11:49:19 -0700
> Cc: emacs-devel@gnu.org, luangruo@yahoo.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-09-05 11:02, Eli Zaretskii wrote:
> 
> > I'm talking about what's in the sig2str.h header.  The above URL says
> > nothing about it.  Why cannot Gnulib arrange for that header to
> > declare these functions and that macro, if signal.h didn't?
> 
> Because then callers might easily make the mistake of thinking that they 
> should include <sig2str.h> to declare sig2str. 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.

> >> 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's sig2str module depends on its signal-h module, so other 
> projects that use sig2str get the POSIX-compatible API with no fuss. The 
> MSVC port of Emacs is a special case

There's no MSVC port of Emacs, not for many years.

> I doubt whether any other project does anything similar. If there is 
> one, it will have its own special reasons and will need to accommodate 
> them. If that ever happens, we can then worry about whether its 
> accommodations can be shared via Gnulib with Emacs's; this will surely 
> affect many functions other than sig2str. In the meantime, as you 
> mentioned the Emacs patch I proposed is good enough to solve this 
> particular problem.
> 
> 
> > Once again, assuming every program that needs sig2str should also use
> > the Gnulib signal.h header is IMO wrong.
> 
> The issue is not just sig2str; it's also sigaction and many other 
> functions. And the issue is not limited to signal.h; it's also present 
> in stdio.h and many other standard headers. Gnulib's design principle is 
> to make the API resemble the GNU API as best it can. Of course that 
> principle could be changed if needed, but any such change should be 
> discussed on bug-gnulib@gnu.org, as it's a much bigger issue than just 
> sig2str and Emacs.

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.