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
On Wed, 2013-05-01 at 20:38 -0700, Jim Michaels wrote:
again, problem solved with what I proposed. think. separate shell
window for each job.
You can do that today by just writing your recipes such that they start
a screen session or xterm or whatever. Those tools allocate and manage
their
OK
From: Paul Smith psm...@gnu.org
To: Jim Michaels jmich...@yahoo.com
Cc: bug-make@gnu.org bug-make@gnu.org
Sent: Thursday, May 2, 2013 4:41 AM
Subject: Re: feature request: parallel builds feature
On Wed, 2013-05-01 at 20:38 -0700, Jim Michaels wrote:
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
With this simple Makefile:
all:
@echo foobar!
true
I get:
D:\gnu\make-3.82.90_GIT_2013-05-01gnumake -j -f mkfsync1
foobar!
true
which is expected, but:
D:\gnu\make-3.82.90_GIT_2013-05-01gnumake -j -f mkfsync1 -O
true
foobar!
Is this also expected? (I see the same
On Thu, 2013-05-02 at 20:30 +0300, Eli Zaretskii wrote:
With this simple Makefile:
all:
@echo foobar!
true
Yes this is a bug. I thought of this while we were having our
discussion yesterday. Unfortunately in all our tests we were using @
to silence make's output of the
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
