Re: [groff] Loss of MSVC support

[Eli Zaretskii]

> Date: Thu, 14 Feb 2019 20:10:31 +0000
> From: Colin Watson <address@hidden>
> 
> Gnulib also doesn't operate simply in terms of one-to-one function
> replacement; for example, it does already provide some process-spawning
> functions that are implemented in terms of Windows or Unix APIs as
> appropriate, although I haven't looked into whether they'd meet groff's
> requirements.

For this to be useful, Someone™ on the Groff team should modify the
code (sometimes in significant ways) to use those Gnulib functions.
Until that happens, the few _WIN32 here and there can hardly be
expected to disappear.

> > I doubt that.  The vast majority of those I see in the current sources
> > deal with issues that Gnulib cannot fix:
> 
> Hmm.  Most of the ones you mention look like things that appear to be
> either very much fixed by Gnulib or at least tractable.
> 
> >   . absence of SIGPIPE
> 
>   
> https://www.gnu.org/software/gnulib/manual/html_node/signal_002eh.html#signal_002eh
>   https://www.gnu.org/software/gnulib/MODULES.html#module=sigpipe

The problem is not that SIGPIPE is not defined as a macro, the problem
is that Windows doesn't generate SIGPIPE (nor any signal, in the Posix
sense, for that matter), and the situation that on Posix hosts
delivers that signal doesn't cause I/O functions on Windows to return
with EPIPE immediately.  I don't see how this could be fixed without
replacing all the relevant I/O functions.

> (groff is actually doing something a bit more complicated involving
> error detection on an output stream, but I wouldn't want to bet that
> Gnulib couldn't handle it, perhaps via something like the "fwriteerror"
> module.)

Using fwriteerror would AFAICT require considerable changes in how
printer.cpp, and probably other modules as well, do I/O.

> >   . backslashes as directory separators
> 
> This ifdef could probably be eradicated using:
> 
>   https://www.gnu.org/software/gnulib/MODULES.html#module=filename

That just allows you to parse file names portably, but it doesn't
_replace_ backslashes with forward slashes.  We need the latter.

> Also, one of the relevant #ifdefs is in
> src/libs/libgroff/localcharset.c, which seems to be a somewhat old copy
> of https://www.gnu.org/software/gnulib/MODULES.html#module=localcharset;
> using the latter would likely make it easier to keep up to date.

I wasn't talking about localcharset.c.

> >   . differences in how argv[0] is presented to 'main'
> 
> I haven't found the bit of groff you're referring to here

See set_current_prefix.

> but it sounds like the sort of thing that Gnulib could fix if its
> "getprogname" module were ported.

Are you sure?  The code is not trivial, and does more than just
finding out the name of the executable program.

> >   . different names of environment variables, like TEMP vs TMPDIR
> 
> Gnulib doesn't handle this today, but it's clear that it could if the
> package using it were using something like the "tmpfile" module.

Right.  But currently Groff doesn't use those more portable
facilities.

> >   . quoting of command arguments 'like this' that isn't supported on
> >     Windows
> 
> This seems like:
> 
>   https://www.gnu.org/software/gnulib/MODULES.html#module=system-quote

No, because Windows needs quoting also when using 'spawn' and 'exec'
family of APIs, not only when using 'system' or invoking programs via
the shell.

> I appreciate this may seem like pedantry, but people who care about
> portability to a given platform should actively prefer things like this
> to be handled by a portability library wherever possible, because then
> it's easier to apply them to more packages.  Further, reducing the
> forest of #ifdefs makes it easier to follow the essential logic of the
> application code rather than having to wade through platform minutiae
> when not actually doing porting work.

I agree.  But this initiative should be picked up by the Groff team,
because it will require non-trivial changes all over the place.  And
in some cases there will still be application-specific issues that no
library, not even Gnulib, can solve.  E.g., see the problem I recently
reported to the bug tracker with file names with backslashes that
cause garbled diagnostics from troff.

> Importing more modules from Gnulib is typically a matter of adding them
> to gnulib_modules in bootstrap.conf and rerunning ./bootstrap, so it
> should be quite an accessible thing for somebody to try who has access
> to both Windows and non-Windows test platforms and wants to try to
> reduce the Windows support burden in groff.

AFAIK, that burden is mostly limited accepting patches and having to
deal with occasional #ifdef.  The latter is indeed a burden, but IME
it's not a significant one, given the small number of them in Groff
(20, to be exact).  Which I think goes a long way towards explaining
why no one made it their priority to perform the radical non-trivial
changes required to remove some of them from Groff, something that
requires good knowledge of the overall design and implementation of
the package as a whole.  If someone does start working on that, I at
least will gladly assist them and help in any way I possibly can.

Thanks.