[Groff] Re: Problem with grohtml on Win32

[Keith MARSHALL]

Hi Gaius,

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

In my copy of aclocal.m4, I now have:

    # Check location of `gs'...
    # (allow --with-gs=PROG option to override).

    AC_DEFUN([GROFF_GHOSTSCRIPT_PATH],
      [AC_ARG_WITH([gs],
        [AC_HELP_STRING([--with-gs=PROG],
          [[/path/]name of ghostscript executable])],
        [GHOSTSCRIPT=$withval],
        [AC_CHECK_TOOLS(GHOSTSCRIPT, [gs gswin32c gsos2], [missing])])
       test "$GHOSTSCRIPT" = "no" && GHOSTSCRIPT=missing
      ])

(note that I have added gswin32c, which is the name Aladdin give to the
command line version of gs, in their Win32 distribution.  Also note the
'test "$GHOSTSCRIPT" = "no" ...' line;  this handles the case where a
user configures using '--without-gs', which sets GHOSTSCRIPT=no.  This
could be omitted, if we arranged to handle GHOSTSCRIPT=no instead of,
or as equivalent to, GHOSTSCRIPT=missing everywhere else).

This is effectively the compromise you suggest -- it places only the
name of the ghostscript executable in the DESC file, leaving pre-grohtml
to locate it, by an implicit PATH search in the system() call.  This way,
groff builds cleanly again, provided I have a ghostscript executable in
my PATH, (which I do), whether I leave it named as gswin32c.exe, or
rename it as gs.exe -- which I prefer, because it is less to type, when
I want to invoke it manually :-)

This just leaves one problem -- when the build host and the ultimate
runtime host disagree on the naming of the ghostscript executable, or if
the runtime host doesn't have such an executable in the PATH, then image
generation in pre-grohtml will fail.  I certainly agree that pre-grohtml
*should* perform a PATH search for the ghostscript executable, during
initialisation, and issue an explicit diagnostic message if it can't be
found -- the default

    Calling 'echo showpage | gs ...' returned status 255

doesn't really convey much useful information to the end user :-(

If we implement such a PATH search, then it shouldn't require too much
additional effort to code a search for each of the well known executable
names in turn, accepting the first successful match, or issuing the
diagnostic if no suitable candidate is found.  If we adopt this policy,
then IMHO, it becomes an entirely moot issue whether the image generator
name is recorded in the DESC file or not -- I can see no real need for it.

What do you think?

Best regards,
Keith.