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
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to