libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI [PATCH] libtool: minimise forks per invocation under bash.


From: Eric Blake
Subject: Re: FYI [PATCH] libtool: minimise forks per invocation under bash.
Date: Mon, 19 Dec 2011 06:50:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/18/2011 06:33 AM, Gary V. Vaughan wrote:
>>> Can anyone think of something better than just removing the whole 
>>> lt_HAVE_PLUSEQ_OP
>>> clause from the patch quoted above, and letting the shell figure it by 
>>> itself later
>>> on?
>> Adding an extra eval seems to do the trick:

Yes - hiding behind eval is the only way to use shell extensions that
not all shells will parse.

>>
>>  eval 'test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))"'
>>
>> Of course, a comment about why this eval is needed would be definitely
>> warranted.
> 
> Not that I've looked at the implementation, but isn't eval as bad as a fork on
> Windows? (which is the only reason to avoid forks, since they are extremely 
> cheap on
> Unix.)

No.  eval doesn't fork.

> 
>> Or, to be even safer, you could directly poke at $BASH_VERSION instead:
>>
>>  case $BASH_VERSION in
>>    [12].*|3.0.*) ;;
>>    *) lt_HAVE_PLUSEQ_OP=yes;;
>>  esac
> 
> Ah, true... I guess I was too focussed on a straight forward one liner, and 
> missed
> the obvious one.  D'oh!  I'll switch to that and push presently.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]