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
