[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: patch to support output synchronization under -j
From: |
Tim Murphy |
Subject: |
Re: patch to support output synchronization under -j |
Date: |
Thu, 14 Apr 2011 20:46:16 +0100 |
That was a confused email - apologies. I will rethink it and return. :-)
On 14 April 2011 20:43, Tim Murphy <address@hidden> wrote:
> ---------- 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/
>
--
You could help some brave and decent people to have access to
uncensored news by making a donation at:
http://www.thezimbabwean.co.uk/
- Re: patch to support output synchronization under -j, (continued)
- Re: patch to support output synchronization under -j, Howard Chu, 2011/04/15
- Re: patch to support output synchronization under -j, Tim Murphy, 2011/04/15
- Re: patch to support output synchronization under -j, David Boyce, 2011/04/14
- Re: patch to support output synchronization under -j, Paul Smith, 2011/04/14
- Re: patch to support output synchronization under -j, Howard Chu, 2011/04/14
- Re: patch to support output synchronization under -j, Paul Smith, 2011/04/14
- Message not available
- Fwd: patch to support output synchronization under -j, Tim Murphy, 2011/04/14
- Re: patch to support output synchronization under -j,
Tim Murphy <=
- Re: patch to support output synchronization under -j, Tim Murphy, 2011/04/14
- Re: patch to support output synchronization under -j, Paul Smith, 2011/04/14
- Re: patch to support output synchronization under -j, Tim Murphy, 2011/04/15
- Re: patch to support output synchronization under -j, Paul Smith, 2011/04/15
- Re: patch to support output synchronization under -j, J.T. Conklin, 2011/04/14