That was a confused email - apologies. I will rethink it and return. :-) On 14 April 2011 20:43, Tim Murphy <tnmur...@gmail.com> wrote: > ---------- Forwarded message ---------- > From: Tim Murphy <tnmur...@gmail.com> > Date: 14 April 2011 20:43 > Subject: Re: patch to support output synchronization under -j > To: psm...@gnu.org > > > 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 <psm...@gnu.org> wrote: >> On Thu, 2011-04-14 at 14:08 -0400, David Boyce wrote: >>> On Thu, Apr 14, 2011 at 1:29 PM, Paul Smith <psm...@gnu.org> 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 <psm...@gnu.org> 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 >> Bug-make@gnu.org >> 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/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make