Bill Meier wrote:
>So:
>
> We should add 'cat' to the list of tools checked.
I have been thinking about this. We could either do that or, perhaps somewhat perversely, we could use an alternative based on an already required application such as Perl or Python. Also, we don't necessarily care that it's only a cygwin cat, but that it's a functional cat that will work with long Windows names.
What we do actually care about is that "which" is the cygwin version. If it isn't, uses such as this will certainly fail:
APP_PATH=`cygpath --unix $APP`
if [ -x "$APP_PATH" -a ! -d "$APP_PATH" ] ; then
APP_LOC="$APP_PATH"
else
APP_LOC=`which $APP_PATH 2> /dev/null`
fi
>It also sounds like:
> We should require certain tools (bash, bison,...,sed,,...)
> (in addition to the already checked /usr/bin/find) should
> be in /usr/bin.
>
> Does this seem too restrictive ?
Yes, but I have an idea. We could leave the verify_tools target as it is and add a troubleshoot_tools target which could report the locations of all of these and perhaps make some suggestions about what might be wrong, including, if found, that a version of bison being used was not the right one. That way, we could continue to improve the Windows build experience without arbitrarily limiting options or unduly interfering with currently working systems.
Ideally, we'd have a usable autotools for Windows, but that does not exist.
> ISTR previous cases where something other with the same
> name as a cygwin exec (e.g. sed) was found because of the
> way PATH was set up.
Yes, and I have personally had a problem in which an old version of unzip was interfering, which I reported here last year. http://www.wireshark.org/lists/wireshark-dev/201002/msg00002.html
Ed
