Re: groff 1.23.0.rc4 on mingw

[G. Branden Robinson]

Hi Bruno,

At 2023-04-16T00:08:54+0200, Bruno Haible wrote:
> On mingw, I see a compilation error:
> 
> ../src/preproc/html/pre-html.cpp: In function ‘int main(int, char**)’:
> ../src/preproc/html/pre-html.cpp:1807:28: error: ‘WEXITSTATUS’ was not 
> declared in this scope
>      if (WEXITSTATUS(wstatus) != 0)
>                             ^
> make[1]: *** [Makefile:8179: src/preproc/html/pre-html.o] Error 1

This is a regression, then, from groff 1.22.4, but I'm not sorry about
it.  We really needed this change.  Debugging groff's production of HTML
is challenging for architectural reasons, but also thanks to
implementation details.

https://savannah.gnu.org/bugs/?60782

The good news is that if someone undertakes and resolves the "small"
problem of enhancing tbl(1) to produce HTML tables, then (thanks to
MathML being a thing) my understanding is that we can drop the pre-html
preprocessor altogether, stop running troff twice on every document when
generating HTML, and enjoy one hell of a performance improvement.

Not a minor effort, but a major payoff.

https://savannah.gnu.org/bugs/?60052

> The fix can be to use the 'sys_wait' module from Gnulib. See
> https://www.gnu.org/software/gnulib/manual/html_node/sys_002fwait_002eh.html

Okay.  Looks like some exciting conversations between Bertrand and me
are in the pipeline.  :)

> Note 1: The comments in the file pre-html.cpp say
>   "// Most MS-DOS and Win32 environments will be missing the 'fork'
>    // capability (some, like Cygwin, have it, but it is better avoided).
>   "
> However, because on Cygwin, neither of the macros __MSDOS__, _WIN32 is
> defined, the code in pre-html.cpp *will* use fork() on Cygwin. Which
> works fine, but is known to be slow. However, I don't know whether the
> native Windows code (_WIN32) will work on Cygwin: many native Windows
> APIs don't work right from within Cygwin, because the worlds inside
> and outside a Cygwin process are quite different.
> 
> 
> Note 2: char_buffer::run_output_filter uses two different
> implementations for spawning a child process, one for Unix, one for
> Windows.

Right.

> This can be simplified to a single implementation for both, based on
> posix_spawn. Gnulib implements posix_spawn also for native Windows;
> see https://savannah.gnu.org/news/?id=10219 .

To make sure I understand clearly, do you expect gnulib's posix_spawn to
resolve _both_ of the above issues (notes 1 and 2)?

Much of pre-html dates back to 2001 or 2002.  The pain of achieving a
portable implementation is obvious to anyone who inspects its source.
I'll bet Gauis Mulley would have been thrilled to have gnulib's
posix_spawn way back then.  :)

Regards,
Branden

signature.asc
Description: PGP signature