Fwd: patch to support output synchronization under -j

[Tim Murphy]

---------- Forwarded message ----------
From: Tim Murphy <address@hidden>
Date: 14 April 2011 20:43
Subject: Re: patch to support output synchronization under -j
To: address@hidden


The reason for splitting stderr and stdout is to do with deadlock and
reading pipes. IIRC.  e.g. blocking on a read to stderr which will
never return because the process is stuck waiting for you to read from
it's stdout.  I think it's all easier on an os where you can create
ptys (is that the term?)  i.e. fake "consoles" to which stdout and
stderr are both attached.

 I am going to be lazy and let someone else justify this or shoot it
down.  Perhaps I will remember why I got into trouble with it a long
time ago.

In practice the non-interleaving is actually nice in examples I've
seen because the context is obvious from the error message itself
(otherwise its' a crap error message and needs updating) and the
division makes it  a little easier to scan for error messages
automatically.

It's more of a problem where you're running a task that executes some
long sub-build.

Regards,

Tim


On 14 April 2011 20:16, Paul Smith <address@hidden> wrote:
> On Thu, 2011-04-14 at 14:08 -0400, David Boyce wrote:
>> On Thu, Apr 14, 2011 at 1:29 PM, Paul Smith <address@hidden> wrote:
>> > One example: I think saving stdout and stderr to different files and
>> > then printing them separately is problematic; consider if your recipe
>> > prints lots of information lines, with errors (to stdout) interspersed.
>> > If you throw all the errors to the end you lose a lot of context.
>>
>> The reason is that the SHELL variable is used not only for recipes but
>> also for the $(shell) function. Intermingling stdout and stderr in the
>> result of $(shell) is just disastrously wrong (as I found in the first
>> iteration of syncsh). I spent some time trying to find a way to
>> determine, from inside a child shell, whether we were forked by a
>> recipe or by $(shell) but could find no reliable way. Thus syncsh was
>> forced to keep them in separate files. Since $(shell) invocations are
>> not "jobs" according to make's process model there's no need for them
>> to participate in synchronization at all, so it may be that within
>> make there's a way to only sync on recipes which in turn would allow
>> 2>&1.
>
> Your latter statement is absolutely correct: it's wrong for $(shell ...)
> to synchronize.  Shell function output is captured by make, not printed
> to stdout, so synchronizing it doesn't make much sense.
>
>> Of course, either way some context is lost. If you put both into one
>> temp file you lose track of which was which; if you keep them in
>> separate files you lose ordering instead. So it becomes a matter of
>> taste, or perhaps an option though that seems like a bit too much to
>> me.
>
> I agree that adding an option seems like a lot.
>
> I think it's more important to maintain ordering of stdout/stderr than
> it is to allow individual redirection.
>
> However, you could do both with some heuristics.  Hm.  Maybe not.  I was
> going to say you could merge them if stdout and stderr were going to the
> same tty or file, but I don't think there's any good way in UNIX to know
> whether two file descriptors are pointing at the same file/device.  Hrm.
> In Linux you can find out via /proc but that's a pretty special case.
>
> --
> -------------------------------------------------------------------------------
>  Paul D. Smith <address@hidden>          Find some GNU make tips at:
>  http://www.gnu.org                      http://make.mad-scientist.net
>  "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
>
>
> _______________________________________________
> Bug-make mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-make
>



--
You could help some brave and decent people to have access to
uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/



-- 
You could help some brave and decent people to have access to
uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/