Re: [groff] Loss of MSVC support

[Eli Zaretskii]

> Cc: address@hidden
> From: Keith Marshall <address@hidden>
> Date: Wed, 13 Feb 2019 03:01:38 +0000
> 
> > You seem to be saying that we *cannot* require C99/POSIX conformance
> > from toolchains on target systems without critical breakage.
> 
> That's exactly what I'm saying.  POSIX requires fork(2); Windows doesn't
> support it.  Where groff sets up a pipeline, using fork(2) and exec(3),
> with I/O hook-up performed between, Windows *must* perform the I/O
> hook-up in the parent, then call spawn(), (or the significantly uglier
> CreateProcess()), to invoke the child, and then revert the effect of the
> I/O hook-up in the parent.  There is no other way of getting around this
> Windows limitation; that's the purpose of the bulk of groff's
> Windows-specific code, and the spawn() API has remained substantially
> unchanged, in over 20 years.

Just to make what Keith says (and I concur) crystal clear: there's a
need to distinguish between C99 compliance of the compiler and the
C99/Posix compliance of the C runtime.  We can assume the former,
certainly when using MinGW GCC, but we cannot assume the latter when
building a native MS-Windows port (as opposed to Cygwin port) of
Groff.  I doubt that Griff nowadays includes support for MSVC, the
Microsoft compiler, I think that all those #ifdef _WIN32 parts are for
any native MS-Windows build, including MinGW: they are there because
MSVCRT.DLL, the Windows C runtime library, lacks many Posix functions.

> > How does the build recipe work under Winows? Does it run shell and m4?
> 
> How it works with MSVC, or with DJGPP, I don't know.

DJGPP has working ports of Bash, m4, and Perl, so it runs the GNU
configury like Posix hosts.

> For MinGW, it uses the conventional GNU build model, (in MinGW's
> MSYS environment).

Right.