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
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,
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
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Thu, 02 May 2013 16:21:36 -0400
The one and only difference between them is that when running a
recursive make, -Otarget WILL NOT capture the output of the sub-make,
leaving whatever it prints going to
On Fri, 2013-05-03 at 09:50 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Thu, 02 May 2013 16:21:36 -0400
The one and only difference between them is that when running a
recursive make, -Otarget WILL NOT capture the
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Fri, 03 May 2013 07:47:09 -0400
The way the user experiences the -Ojob option's results is that the
output of every line of each recipe is dumped as soon as that line is
complete.
I would suggest
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Fri, 03 May 2013 09:08:27 -0400
You're concentrating on the one recursive make target and saying
this doesn't follow the rule, while I'm concentrating on all
targets in the sub-make and saying let's
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
One optimisation I have thought of in the past for this situation would be
to allow a single job to hold onto the lock when it obtained it.
This way it could output directly to the console while all other jobs would
have to buffer. When it released, the next job lucky enough to grab the
lock
Eli Zaretskii e...@gnu.org writes:
If you want different behavior you can change your rule to use + on
the two echo lines, so that they're also considered recursive and not
saved up.
If I do that, the echo from rec1 and rec2 mix up:
D:\gnu\make-3.82.90_GIT_2013-05-01gnumake -f
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Thu, 02 May 2013 08:21:23 -0400
Now, if you do nothing special for recursive make, you'll get no output
from the entire build until it is completely done, because all the
output from the recursive
On Thu, 2013-05-02 at 20:24 +0300, Eli Zaretskii wrote:
The desired results in my original use case are that the output of
remaking each target is shown as one chunk in the order in which it is
expected, i.e. from the first command to the last. Remaking a
target, a.k.a. recipe in this context
On Tue, 2013-04-30 at 10:39 -0400, Paul Smith wrote:
On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
On 04/30/2013 03:37 PM, Paul Smith wrote:
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test
Hi Paul.
On 05/01/2013 02:04 PM, Paul Smith wrote:
On Tue, 2013-04-30 at 10:39 -0400, Paul Smith wrote:
On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
On 04/30/2013 03:37 PM, Paul Smith wrote:
Just to be clear, you're saying that the testsuite runs as one long
operation,
From: Paul Smith psm...@gnu.org
Date: Wed, 01 May 2013 08:04:08 -0400
Cc: bug-make@gnu.org
This should work very well with -Otarget then, except for the
colorization/highlighting issue... once it works as expected. I'll look
into this issue later and I would be interested to see your
On 05/01/2013 05:26 PM, Eli Zaretskii wrote:
Unfortunately, the delays are still here.
I can say they're no longer there *in my use case*; I haven't tested
other use cases though. Hope this is sorted out soon...
Thanks,
Stefano
___
Bug-make
On Wed, 2013-05-01 at 18:26 +0300, Eli Zaretskii wrote:
You forgot to make the same change in the WINDOWS32 branch. I did
that in commit a87ff20.
Sorry, I missed that.
This should be fixed now. Those who use recursive makefiles and were
seeing annoying delays in output with -O, please
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Wed, 01 May 2013 14:41:25 -0400
Unfortunately, the delays are still here.
Very odd. This is the test program I used; can you verify:
recurse: ; $(MAKE) -f $(firstword $(MAKEFILE_LIST)) all
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Wed, 01 May 2013 14:41:25 -0400
If you want different behavior you can change your rule to use + on
the two echo lines, so that they're also considered recursive and not
saved up.
If I do that, the
On Wed, 2013-05-01 at 22:08 +0300, Eli Zaretskii wrote:
Yes. But I thought the change was about -Otarget, not -Ojob. Stefano
was complaining about a plain -O, so -Ojob is not what was his
problem.
Yes, it is about -Otarget. As I said, I added -Ojob output just for
completeness. The
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Wed, 01 May 2013 16:27:58 -0400
If your recipe normally runs for 5 seconds (say) and it continually
generates output during that time, then yes, certainly the -O feature
will result in choppiness
I'm sorry to say that the new -O option can interact *badly*
with Automake-generated parallel testsuites (at least when they
are being run interactively, that is, with the output of make
connected to a tty).
Let me elaborate a little (if you still have doubts or objections
after reading the
I'm guessing here but I imagine the main problem comes with delaying the
results of submakes?
I haven't tested to see if this is how the new feature works or not. I
don't think it's completely necessary to keep all output from one submake
together. so turning that off might make things more
What I mean is that:
./make -Otarget
might be a good interactive default rather than -Omake.
Colouring is another issue which I would imagine could be done another way
to let us have the best of both worlds.
Regards,
Tim
On 30 April 2013 10:55, Tim Murphy tnmur...@gmail.com wrote:
I'm
On 04/30/2013 11:55 AM, Tim Murphy wrote:
I'm guessing here but I imagine the main problem comes with delaying the
results of submakes?
I think so, yes. The Distributed Make from Sun implements a similar
output synchronization feature, and doesn't have the output delay problems
I have
On 04/30/2013 12:01 PM, Tim Murphy wrote:
What I mean is that:
./make -Otarget
might be a good interactive default rather than -Omake.
I wasn't even aware of those differences; as of latest Git commit
'moved-to-git-46-g19a69ba', I don't see them documented in either
the help screen, the
I know this isn't going to go down all that well, but I really think the
output should be annotated in such a way that colourisation could be
applied to the log file after a build has already finished.
e..g you load a makefile into VIM - it can colourise it. Or a bit of C
source code. Why not the
On 04/30/2013 01:22 PM, Tim Murphy wrote:
I know this isn't going to go down all that well, but I really think the
output should be annotated in such a way that colourisation could be
applied to the log file after a build has already finished.
While this might (underline might ;-) be an
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test script,
right? I can see how that environment might be problematic for this new
feature. It works much better for lots of smaller targets.
However, you could avoid
Hi Paul.
On 04/30/2013 03:37 PM, Paul Smith wrote:
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test script,
right?
No; the testsuite runs as a recursive make invocation (yes, this is sadly
truly needed in order
On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
On 04/30/2013 03:37 PM, Paul Smith wrote:
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test script,
right?
No; the testsuite runs as a recursive
34 matches
Mail list logo
