> From: Paul Smith
> 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 the same
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 thi
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 t
With this simple Makefile:
all:
@echo foobar!
true
I get:
D:\gnu\make-3.82.90_GIT_2013-05-01>gnumake -j -f mkfsync1
foobar!
true
which is expected, but:
D:\gnu\make-3.82.90_GIT_2013-05-01>gnumake -j -f mkfsync1 -O
true
foobar!
Is this also expected? (I see the sam
> From: Paul Smith
> 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 m
Eli Zaretskii 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-01>gnumake -f mkfsyn
OK
>
> From: Paul Smith
>To: Jim Michaels
>Cc: "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:
>
>> again, problem solved with what I
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
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 mi
