On Thu, Apr 14, 2011 at 1:29 PM, Paul Smith <psm...@gnu.org> wrote: > I've looked at it and as a concept I don't have too many issues with it
Thanks. > 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. I actually think this is unavoidable. At least it's unavoidable when using a separate shell wrapper; it may be possible to better internally to make with some extra work. 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. 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. David _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make