Date: Sun, 05 May 2013 20:17:50 +0300
From: Eli Zaretskii e...@gnu.org
Cc: bug-make@gnu.org
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sun, 05 May 2013 12:56:48 -0400
On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
However, I wonder what was the reason
On Sun, 2013-05-05 at 00:44 +0200, Stefano Lattarini wrote:
The test 'features/output-sync' now fails for me:
Test timed out after 6 seconds
Error running /storage/home/stefano/src/gnu/make/tests/../make \
(expected 0; got 14): /storage/home/stefano/src/gnu/make/tests/../make \
Hi Paul.
On 05/05/2013 08:19 AM, Paul Smith wrote:
On Sun, 2013-05-05 at 00:44 +0200, Stefano Lattarini wrote:
The test 'features/output-sync' now fails for me:
Test timed out after 6 seconds
Error running /storage/home/stefano/src/gnu/make/tests/../make \
(expected 0; got 14):
On Sun, 2013-05-05 at 11:11 +0200, Stefano Lattarini wrote:
Sorry to add this only now, but I realized the failure is only
reproducible if I run the testsuite with make -j, as in make -j8
check; and even in that case, the failure is racy. With a bare make
check, things work for me as well.
From: Paul Smith p...@mad-scientist.net
Cc: bug-make@gnu.org
Date: Sat, 04 May 2013 17:51:05 -0400
Eli, I did some cleanup in job.c to try to make things simpler and
reduce duplication. I tried to be careful but it's quite possible I did
something to disrupt the Windows version again.
On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
However, I wonder what was the reason for splitting the definition of
GMK_EXPORT in two, and putting each part in a different file.
Well, because the gnumake.h file is intended to be installed into the
user's /usr/include or similar, and
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sun, 05 May 2013 12:56:48 -0400
On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
However, I wonder what was the reason for splitting the definition of
GMK_EXPORT in two, and putting each part in a different file.
Well,
On 05/05/2013 05:30 PM, Paul Smith wrote:
On Sun, 2013-05-05 at 11:11 +0200, Stefano Lattarini wrote:
Sorry to add this only now, but I realized the failure is only
reproducible if I run the testsuite with make -j, as in make -j8
check; and even in that case, the failure is racy. With a bare
On Sun, May 5, 2013 at 2:49 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 05/05/2013 05:30 PM, Paul Smith wrote:
On Sun, 2013-05-05 at 11:11 +0200, Stefano Lattarini wrote:
Sorry to add this only now, but I realized the failure is only
reproducible if I run the testsuite with
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Fri, 03 May 2013 17:17:44 -0400
-O in no way changes that behavior, all it does is ensure that output
from any individual line or target of the recipe will not interfere with
any other individual line
On Fri, 2013-05-03 at 12:55 -0400, Paul Smith wrote:
Suppose we do this: if we're about to invoke a line marked recursive
and we're in -Otarget mode, then before we run it we'll show the
current contents of the temp file (using the normal synchronized
output function).
I've implemented this
Hi Paul.
On 05/05/2013 12:10 AM, Paul Smith wrote:
On Fri, 2013-05-03 at 12:55 -0400, Paul Smith wrote:
Suppose we do this: if we're about to invoke a line marked recursive
and we're in -Otarget mode, then before we run it we'll show the
current contents of the temp file (using the normal
I have a solution for this problem that I think will work well, and will
be simple to implement.
Suppose we do this: if we're about to invoke a line marked recursive and
we're in -Otarget mode, then before we run it we'll show the current
contents of the temp file (using the normal synchronized
13 matches
Mail list logo
