[Top][All Lists]

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

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

From: Frank Heckenbach
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Thu, 18 Apr 2013 22:36:15 +0200

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:

        @echo foo:error

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

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
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.

reply via email to

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