On 12/08/2011 09:29 AM, Charles Wilson wrote:
Has anybody done a comparison between:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
cygwin + libtool + bash (e.g. big bloated slow shell -- with XSI)
to see which is better?
Because I installed mingw32 yesterday on my rar
On 12/8/2011 11:22 AM, Eric Blake wrote:
> On 12/08/2011 08:29 AM, Charles Wilson wrote:
>> cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
>
> Umm, dash has XSI features (where XSI features covers things like
> ${var##prefix}). ... Meanwhile, libtool is using more than just X
On 12/08/2011 08:29 AM, Charles Wilson wrote:
> On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
>> The recently pushed series of patches included the controversial
>> introduction of an additional 3 forks per invocation, which might
>> add a minute or two of wall-clock time to giant builds on windows.
On Thu, 8 Dec 2011, Peter O'Gorman wrote:
Any additional forks will slow down the script and should be avoided on all
platforms.
I definitely agree with that. Besides the Windows problem, it does
not seem like fork performance improves linearly from adding processor
cores so it is importan
On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
> The recently pushed series of patches included the controversial
> introduction of an additional 3 forks per invocation, which might
> add a minute or two of wall-clock time to giant builds on windows.
> By assuming that windows will run shell scripts
On 12/08/2011 08:04 AM, Bob Friesenhahn wrote:
> On Thu, 8 Dec 2011, Gary V. Vaughan wrote:
>>>
>>> Instead of doing it this way, I'd almost rather see:
>>>
>>> if test "${BASH_VERSION+set}" = set; then
>>
>> Face palm! Absolutely, that is far more sensible. Assuming we decide
>> to push this pat
On Thu, 8 Dec 2011, Gary V. Vaughan wrote:
Instead of doing it this way, I'd almost rather see:
if test "${BASH_VERSION+set}" = set; then
Face palm! Absolutely, that is far more sensible. Assuming we decide
to push this patch, I'll do it that way and ditch the host check. Thanks!
Is the
On 12/08/2011 08:03 AM, Gary V. Vaughan wrote:
Any additional forks will slow down the script and should be avoided on all
platforms.
Agreed.
Following up just because "slow down" is not a number:
touch a.c
time (for x in {1..100}; do ./libtool --mode=compile --tag=CC gcc -c -o
a.lo a.c;
Hi Eric,
On 8 Dec 2011, at 19:56, Eric Blake wrote:
> On 12/08/2011 03:21 AM, Gary V. Vaughan wrote:
>> The recently pushed series of patches included the controversial
>> introduction of an additional 3 forks per invocation, which might
>> add a minute or two of wall-clock time to giant builds on
Hi Peter,
On 8 Dec 2011, at 20:40, Peter O'Gorman wrote:
> On 12/08/2011 04:21 AM, Gary V. Vaughan wrote:
>> The recently pushed series of patches included the controversial
>> introduction of an additional 3 forks per invocation, which might
>> add a minute or two of wall-clock time to giant buil
On 12/08/2011 04:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on s
Hi Eric.
On Thursday 08 December 2011, Eric Blake wrote:
>
> Instead of doing it this way, I'd almost rather see:
>
> if test "${BASH_VERSION+set}" = set; then
>
> although if cygwin ever follows debian's lead of using dash for faster
> /bin/sh, I'm not sure if there is a reliable forkless way t
On 12/08/2011 03:21 AM, Gary V. Vaughan wrote:
> The recently pushed series of patches included the controversial
> introduction of an additional 3 forks per invocation, which might
> add a minute or two of wall-clock time to giant builds on windows.
> By assuming that windows will run shell script
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on some shell with
all the modern optional features t
14 matches
Mail list logo
