> Date: Sun, 05 May 2013 20:17:50 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > From: Paul Smith
> > 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 splittin
On Sun, May 5, 2013 at 2:49 PM, Stefano Lattarini
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 "make -j", as in "make
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. Wit
> From: Paul Smith
> 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, beca
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
> 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. It's up to you if
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
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
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 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 norm
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 thi
> From: Paul Smith
> 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 or target
On Fri, 2013-05-03 at 23:12 +0300, Eli Zaretskii wrote:
> > the "start" and "end" will have other stuff (not just the other targets
> > in that sub-make, but ANY other targets that happen to finish during
> > that time) between them.
>
> This last part (about ANY other targets) is not what I thoug
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Fri, 03 May 2013 15:30:18 -0400
>
> On Fri, 2013-05-03 at 21:15 +0300, Eli Zaretskii wrote:
> > > This will ensure that output from lines before the recursive make will
> > > be shown before the targets in the recursiv
On Fri, 2013-05-03 at 21:15 +0300, Eli Zaretskii wrote:
> > This will ensure that output from lines before the recursive make will
> > be shown before the targets in the recursive make. It's not 100%
> > identical but I can't see any way to do better.
>
> Why isn't it identical?
It's not identic
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Fri, 03 May 2013 12:55:26 -0400
>
> 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
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 ou
17 matches
Mail list logo
