Timothy Smith <tim@stripped> writes:
> On Mon, Oct 29, 2007 at 08:12:49PM +0100, kent@stripped wrote:
>> diff -Nrup a/BUILD/autorun.sh b/BUILD/autorun.sh
>> --- a/BUILD/autorun.sh 2006-08-23 22:59:13 +02:00
>> +++ b/BUILD/autorun.sh 2007-10-29 20:10:53 +01:00
>> @@ -3,20 +3,29 @@
>>
>> die() { echo "$@"; exit 1; }
>>
>> -# Added glibtoolize reference to make native OSX autotools work
>> -if [ -f /usr/bin/glibtoolize ]
>> +# Added glibtoolize reference to make native OSX autotools work,
>> +# we pick the first of glibtoolize/libtoolize we find in PATH
>
> A pet peeve of mine: I dislike comments that describe the programmer's
> actions ("Added glibtoolize reference") instead of the program's
> actions. I'd prefer something like:
>
> # Use glibtoolize if it exists (e.g., for native OS X autotools), or
> # fall back to libtoolize.
Ok.
>> +LIBTOOLIZE=libtoolize # Default
>> +IFS="${IFS= }"; save_ifs="$IFS"; IFS=':'
>> +for dir in $PATH
>
> I'm sure there's a reason, but why don't we use 'which'? I know some
> 'which' programs always return success, even if no match is found. Is
> there another problem that makes 'which' unusuable? I think it could
> still be used to fetch the first matching exe in the path.
Several reasons. One is that it is quite hard to use "which" in
a portable way as some write errors to stdout. But for asking
"does it exists" they might be compatible enough.
But I don't want to use glibtoolize over libtoolize, I want to search
the path and pick the first one I can find. Only in the case both
glibtoolize and libtoolize is in the same directory I pick one over
the other. So "which" can't really be used.
>> +do
>> + if test -f $dir/glibtoolize
>
> Why not -x?
No reason, I change it.
<snip>
> It's OK to push, for me. My comments are minor.
Thanks!
kent
--
Kent Boortz, Senior Production Engineer
MySQL AB, www.mysql.com
Office: +46 18 174400 ext. 4450 (VoIP)
Office: +46 19 182931
Mobile: +46 70 2791171
