Re: [bug #33138] .PARLLELSYNC enhancement with patch

[Frank Heckenbach]

Paul Smith wrote:

> On Thu, 2013-04-18 at 20:36 +0200, Frank Heckenbach wrote:
> > And with my progress mechanism, that's exactly what I want. In my
> > case it'd look like this:
> > 
> > [Start] Compiling foo.c
> > [Start] Compiling bar.c
> > # time passes
> > foo.c: some error
> > # time passes
> > bar.c: some error
> > # time passes
> > [End] Compiling bar.c
> > # time passes
> > [End] Compiling foo.c
> > 
> > This is useful (to me) because at any time, I know what's running.
> > ("[Start]" messages minus "[End]" messages.)
> 
> Thanks, this is the reason I was looking for; that use-case wasn't clear
> to me based on the previous email.

OK, so what are we going to do about it? Leave, revert, new option?

Well, right now I did find a problem with the new behaviour:

foo:
        @echo foo:error
        @false

% make -Omake # same with -Otarget
m:2: recipe for target 'foo' failed
make: *** [foo] Error 1
foo:error

This seems at least strange to me: The conclusion "recipe failed" is
printed before the reason (the messages from the job).

Reverting this part (i.e., moving the sync_output() call to where it
was before) corrects this:

% make -Otarget # same with -Otarget
foo:error
m:2: recipe for target 'foo' failed
make: *** [foo] Error 1

To fix it without reverting the behaviour seems to require calling
sync_output() before child_error() (2 places).

> > > Probably we'll want to allow the user to
> > > have more control over it, as well.  Maybe a similar flag that lets you
> > > choose whether to trace on a per-target or per-make basis.
> > 
> > I think it should in principle be possible without requiring the
> > user to specify any more options.
> 
> I was thinking more that the user may want to not want all the
> enter/leave output even if it is ambiguous from a programmatic sense: I
> know where my code lives and so if I see the my_foo.o fails, I know that
> the my_foo.c file lives in src/my/my_foo.c.  I might prefer to see a
> cleaner output from make and rely on my innate knowledge of the codebase
> to navigate.
> 
> But maybe you'd still like to see the per-make enter/leave, even if
> you're running with -Otarget.

I for my part don't care about individual enter/leave messages since
my script (much like the Emacs mode) interprets them. I only care
that the last enter-message before each message from the job is
correct; any redundant messages before are simply ignored. So as
long as this behaviour remains (or at least an option exists to keep
it), I'm fine with any changes.