[Groff] Re: Problem with grohtml on Win32

[Keith MARSHALL]

Hi Werner, Gaius,

> 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.  [...]

> 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).

On further reflection, I wonder if the logic used to establish the
ghostscript path, as stored in the DESC file, is really appropriate.
In aclocal.m4, in the CVS, I see:

        AC_DEFUN([GROFF_GHOSTSCRIPT_PATH],
          [AC_PATH_TOOL(GHOSTSCRIPT, gs gsos2, missing)
           AC_SUBST(GHOSTSCRIPT)])

In addition to AC_SUBST(GHOSTSCRIPT) being redundant here, because
AC_PATH_TOOL invokes it internally anyway, there are actually two
more serious problems with this:

  1) I assume that the intention here is to search for 'gs', and if
     not found, to look for 'gsos2' as an alternative.  Unfortunately,
     AC_PATH_TOOL will not do this -- it searches *only* for the first
     named program in its second argument.  To search for alternatives,
     AC_CHECK_TOOLS may be used, but that will return only the *name*
     of the first matching program, without its path.  To get the full
     path, *both* AC_CHECK_TOOLS *and* AC_PATH_TOOL must be used, (or
     an AC_PATH_TOOLS macro could be written -- it isn't included in
     the standard autoconf macro set, unless it has been added since
     the release of version 2.56, which is the most recent version
     currently supported by MSYS).

  2) Using GROFF_GHOSTSCRIPT_PATH to establish the 'image_generator'
     entity in the DESC file is invalid, if the build host and target
     platforms are not congruent, wrt the naming and location of the
     ghostscript executable.  Thus, there is a high risk that a cross
     compiled groff will have a broken grohtml.

Any thoughts on how best to fix this?  IMHO, the only really robust
solution may be to have pre-grohtml identify the correct program name,
at run time.

Best regards,
Keith.