On Thu, 2013-04-18 at 22:36 +0200, Frank Heckenbach wrote:
> % 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).

Unfortunately that isn't sufficient either.  It's possible for
child_error() to be invoked, but then we don't stop but continue on with
the recipe (if the error is ignored).  If we ran child_error() here we
would show half the recipe output, then the error message, then the rest
later, in a separate grouping.

I went a different way: I modified the child_error() function so that if
there was an output-sync file, the error message would be written to the
end of that file instead of printed directly.  This way when the output
is shown to the user she sees the entire thing, including error messages
from make, in order.

This also allowed me to drop the layer of enter/leave notices around
error messages.

Please check/verify this change in your own environments.


PS. Some may be tsking to themselves noting this change would have been
a lot simpler if we'd kept a FILE* handle instead of a file descriptor.
Unfortunately it's not clear that would work.  I created a test program
to verify that this method of having the parent append messages to the
file after the child exits, and with a FILE* handle I couldn't make it
work right.  My fseek() after the child exited didn't skip past the
child's output and my message printed by the parent ended up overwriting
that output.  I'm sure it would have worked if I'd closed the file in
the parent and re-opened it, but since I'm using tmpfile() that is not
possible.  I might have done something wrong, but anyway it wasn't a
slam-dunk.


_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Reply via email to