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
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 scripts
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 builds on
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
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: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 patch, I'll do it that
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
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
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.
By
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 XSI
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
11 matches
Mail list logo
