[Groff] Problem with grohtml on Win32

[Keith MARSHALL]

I just tried to build a recent groff CVS snapshot on my Win2K box,
using the MinGW/MSYS tool chain.  All went OK, *except* for image
processing in pre-grohtml -- each image processed generates a pair
of warning messages, the first of which reports:

  ... echo showpage | /path/to/ghostscript ... returned status 255

Processing then continues, but the img tags are not resolved, in
the resultant HTML.

This used to work fine, when pre-grohtml simply assumed that the
ghostscript executable was called 'gs', and that it was located in
the process' PATH -- it now fails, because pre-grohtml uses a fully
qualified path, which is specified in the DESC file, and this path
is invalid for native Win32.  Here's why:

1) MSYS provides a simulated POSIX environment, in which configure
   and make are executed;  MinGW provides GCC, generating executables
   which run in a native Win32 environment.

2) Running configure, in MSYS' simulated POSIX environment, detects
   the ghostscript executable, adding the Makefile entry

   # The name of the ghostscript program. Normally, gs, on GNU/Linux
   # but it might be different on cygwin systems.
   GHOSTSCRIPT=/usr/local/bin/gs

   (This is the POSIX style path, relative to the MSYS root).

3) Running make replicates this in font/devhtml/DESC, as

   image_generator /usr/local/bin/gs

4) pre-grohtml reads this entry from font/devhtml/DESC, appends a
   .exe extension, and tries to invoke it, via a system() call.

5) Win32's MSVCRT spawns cmd.exe to parse the command string passed
   in the system() call; the POSIX style path for the ghostscript
   program name confuses cmd.exe, which aborts with status 255.

I can work around this problem, by manually editing the Makefile
after running configure, and before running make, to change the
automatically detected ghostscript path, discarding the path
information, and thus reverting to previous behaviour, i.e.

   GHOSTSCRIPT=gs

or, retaining the full path specification, I can say

   GHOSTSCRIPT=d:\msys\1.0\local\bin\gs

(Note, if I spell out the full path, I *must* do so using native
 Win32 semantics, and I must include the native resolution of the
 MSYS' pseudo-mount point for /usr, which, in my setup, maps to
 d:\msys\1.0).

While either of these hacks do restore correct behaviour for the
latest pre-grohtml implementation, I do not think it is reasonable
to require them -- IMHO configure should get it right OOTB.  To
achieve this, we could consider the following options:

1) Revert pre-grohtml to its previous behaviour, wrt ghostscript
   invocation -- a backward step, and therefore not desirable.

2) Run the ghostscript detection in configure, but discard all
   path information from the result, retaining only the detected
   program file name, in the generated Makefile -- this will leave
   the system() call within pre-grohtml to perform a PATH search,
   when invoking the specified ghostscript program, but will avoid
   confusing cmd.exe with the POSIX style path name.

3) Run the ghostscript detection, as in option 2, but rather than
   discarding the path information, postprocess it to translate it
   to the appropriate format for the target OS -- probably achievable,
   but undoubtedly more difficult than option 2.

4) Provide a '--with-gs=...' option in configure, to allow the user
   to override the automatic ghostscript detection -- this would
   provide a 'catch all' for situations where the automatic detection
   doesn't work reliably, with a standardised autoconf user interface,
   rather than requiring the user to modify the Makefile *after* it
   is generated (every time).

IMHO, we should aim for a combination of options 3 and 4 -- perhaps
2 and 4, if 3 proves too difficult to implement.

Best regards,
Keith.