help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using shell wrapper for descrambling parallel make output


From: Paul Smith
Subject: Re: Using shell wrapper for descrambling parallel make output
Date: Mon, 14 Nov 2011 14:29:02 -0500

On Mon, 2011-11-14 at 11:46 -0500, David Boyce wrote:
> On Mon, Nov 14, 2011 at 4:29 AM, Atte Peltomäki <address@hidden> wrote:
> > Nice work. Your implementation seems much more refined than mine. Only
> > one thing catches my attention; your version doesn't seem to properly
> > preserve the original line ordering between stdout and stderr. I suggest
> > solving this as I did:
> 
> My problem, aside from limited time of course, is that I have no
> indication yet of whether the patch is likely to be accepted into 3.83
> which in turn has an effect on how much work I want to put into the
> standalone solution. Paul, any chance you can provide a status update
> or thumbs up/down on http://savannah.gnu.org/bugs/?33138?

I think this feature is a good one (I think I said that up-front).  I
will spend some time examining the patch currently attached to the bug
(is that the current version?)

What about when make prints the recipe it's about to invoke?  That
should be captured with the output and all of them printed at the same
time, I'd think.

Also there was a comment at the beginning about whether all the output
from the entire set of recipe lines should be captured together, so the
output from the entire target appears at the same time, or whether we
should be generating them one recipe line at a time so output from
different targets' recipe lines would be intertwined: what was the
resolution there?

Another question.  What about informational lines that are generated by
make?  Things like changing directories or whatever?  What about output
generated by things like $(info ...) inside a recipe script?  How are
these things handled?


I would like to change the name though.  PARALLELSYNC isn't very
descriptive to me... or rather, it implies things which aren't addressed
by this feature.  I would like to have a reference to "output" or
similar in the name.  Maybe ".SYNCOUTPUT" or something?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]