Re: [groff] Loss of MSVC support

[John Gardner]

> 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 <address@hidden> 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 <address@hidden>
> > >
> > > 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                                       address@hidden
>
>