Update of bug #22923 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #9, bug #22923 (project make):
I agree with comment #2 that polling pipes would incur unnecessary overhead
and that the generic solution would pair each spawned action against the
pre-defined template of a logger command.
Looking at the recipient of messages in the existing
Follow-up Comment #8, bug #22923 (project make):
Hi
My team do this with GNU make at the moment by using a replacement shell.
It was proprietary until fairly recently and now it has been released under
the EPL. It is hosted by the Symbian Foundation and you'd need a login but
since it's
Follow-up Comment #5, bug #22923 (project make):
Another idea mentioned in a Python bug discussion on file handles contention
is to have each spawned make process redirect stdout and stderr of its spawned
actions to a socket opened by the main make process. (Perhaps, each make
process could do
Follow-up Comment #6, bug #22923 (project make):
I don't really see the difference between comment #5 and the original
description. I've addressed why this is hard to do in comment #2.
___
Reply to this item at:
Follow-up Comment #7, bug #22923 (project make):
Reaching back 25 years again, this is basically what Alliant Concentrix
parallel make did. It prefixed each output line with the job number |1|, |2|
and so on. (This is also why in my original proposal for make -j, I used
different numbered job
Follow-up Comment #4, bug #22923 (project make):
We have implemented output merging with a shell wrapper script. We ask make
to use this wrapper script via the SHELL variable.
The script itself is pretty simple, although it may be bash-centric:
Additional Item Attachment, bug #22923 (project make):
File name: makesh Size:0 KB
File name: makesh-split Size:0 KB
___
Reply to this item at:
http://savannah.gnu.org/bugs/?22923
Follow-up Comment #3, bug #22923 (project make):
Thanks ipjrest and psmith for both replies. They are very appreciated.
Responding to ipjrest's comments:
=
I agree some commands are long-running and that if watching progress is
important, the proposed behavior
Brian Kustel wrote:
Follow-up Comment #3, bug #22923 (project make):
Thanks ipjrest and psmith for both replies. They are very appreciated.
Responding to ipjrest's comments:
=
I agree some commands are long-running and that if watching progress is
important,
Follow-up Comment #1, bug #22923 (project make):
Some commands are long-running. And while it would be useful for post-build
analysis to have the entire output of each command grouped together, it's much
less fun to watch. :)
Perhaps something like MSFT did with parallel builds in Visual
URL:
http://savannah.gnu.org/bugs/?22923
Summary: option to prevent interspersed output in parallel
builds
Project: make
Submitted by: bkustel
Submitted on: Wednesday 04/16/2008 at 03:26
Severity: 3 - Normal
12 matches
Mail list logo
