> who has access to both Windows and non-Windows tes platforms and > wants to try to reduce the Windows support burden in groff.
Microsoft have a CI service called AppVeyor <https://ci.appveyor.com/> that offers pretty decent build configuration. For a free service, it's actually not bad. There's a paid plan, but you won't need it for something like Groff (the commercial plan is really for corporate-level build farms, a la Chromium's waterfall). This, along with TravisCI <https://travis-ci.org> (macOS / Linux, also free) make cross-platform testing less of a headache... On Fri, 15 Feb 2019 at 07:11, Colin Watson <cjwat...@debian.org> wrote: > 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] > >