> Date: Thu, 14 Feb 2019 20:10:31 +0000 > From: Colin Watson <cjwat...@debian.org> > > 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.
