On Thu, Feb 14, 2019 at 07:30:13PM +0200, Eli Zaretskii wrote: > > Date: Thu, 14 Feb 2019 12:50:09 +0000 > > From: Colin Watson <cjwat...@debian.org> > > > > If it's just the runtime, then Gnulib should be able to paper over a > > pretty fair number of the differences, and groff already uses that. > > Up to a degree. There's no fork for Windows, for example, and many > other functions are missing.
Yeah, I'm not saying it'll cover everything, but it doesn't have to cover everything to be an improvement. 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. > > (It's possible that some of the _WIN32 conditionals can be supplied by > > Gnulib these days, but there's also no great urgency to remove them, > > IMO.) > > 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 (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.) > . backslashes as directory separators This ifdef could probably be eradicated using: https://www.gnu.org/software/gnulib/MODULES.html#module=filename 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. > . differences in how argv[0] is presented to 'main' I haven't found the bit of groff you're referring to here, but it sounds like the sort of thing that Gnulib could fix if its "getprogname" module were ported. > . 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. > . 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 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. 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. -- Colin Watson [cjwat...@debian.org]
