[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] Loss of MSVC support

From: Colin Watson
Subject: Re: [groff] Loss of MSVC support
Date: Thu, 14 Feb 2019 20:10:31 +0000
User-agent: NeoMutt/20170113 (1.7.2)

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

> > (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

(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"

>   . backslashes as directory separators

This ifdef could probably be eradicated using:

Also, one of the relevant #ifdefs is in
src/libs/libgroff/localcharset.c, which seems to be a somewhat old copy
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:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]