From time to time, I've built groff using Microsoft Visual C/C++ and
the MKS Toolkit. The MKS environment provides most of the necessary
Unix-like utilities without much diddling, but not without a few
quirks.
One quirk makes it impossible for configure to detect the path
separator. With the MKS Toolkit (I'm using the current version 9.4),
the test for PATH_SEPARATOR fails because
PATH='/bin:/bin' sh -c:
succeeds because of a quirky way in which MKS handles pathnames. It's
easy enough to call configure with something like
PATH_SEPARATOR=';' configure
_if_ a user knows to do this. It would, of course be preferable to do
this automatically, and it seems to me that it should not be that
difficult. This really is an autoconf issue, but Werner asked me to
mention it here, so I have. Other folks here may have some additional
insights to present to the autoconf people.
If it is known that a particular "os" (e.g., mks) has a semicolon
for the path separator, it may make sense to just set it. I also
assume that if PATH contains a semicolon, the semicolon is the path
separator is a semicolon, so again it may make sense to just set it
without further ado. If neither of these tests is conclusive, the
current test could be done, giving something like
if test "${PATH_SEPARATOR+set}" != set; then
case $ac_canonical_build in
*-*-mks)
PATH_SEPARATOR=';' ;;
esac
fi
if test "${PATH_SEPARATOR+set}" != set; then
case $PATH in
*\;*)
PATH_SEPARATOR=';' ;;
esac
fi
if test "${PATH_SEPARATOR+set}" != set; then
PATH_SEPARATOR=:
(PATH='/bin;/bin'; FPATH=$PATH; sh -c :) && {
(PATH='/bin:/bin'; FPATH=$PATH; sh -c :) ||
PATH_SEPARATOR=';'
}
fi
And the idiosyncrasies continue ... The current test invocation finds
sh on my system only because I have /bin as a symbolic link to c:/
Program Files/MKS Toolkit/mksnt. Now the idea isn't that novel, so I'm
sure some others have also thought of it. But it's certainly not
something that can be assumed. If sh cannot be found, PATH_SEPARATOR
is set to ':', which doesn't make sense to me (wouldn't any Unix-like
system always have /bin/sh?).
It might be assumed that nothing would work on a system for which
/bin/sh is not available because of the line
#! /bin/sh
that begins the configure script.
But this isn't true for MKS, which by default searches PATH for the
basename of the specified command interpreter if the full pathname
doesn't exist (in general, this probably makes sense to accommodate
scripts that expect /bin/sh rather than the MKS location).
The possible code above still may not be perfect, but it would arguably
be an improvement--but perhaps the good should not be rejected for the
perfect.
Any thoughts?
Jeff Conrad
