[Groff] Re: Problem with grohtml on Win32

[Gaius Mulley]

Keith MARSHALL <address@hidden> writes:

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

Hi Keith,

how about moving back to using `gs' in the DESC file, but supplying
extra checking code in pre-grohtml which tests whether the executable
`gs' is currently in the path and issue a specific warning if it is
not? Not as nice as solving (1) above but perhaps a reasonable
compromise..

regards,
Gaius