|
From: | Tim Murphy |
Subject: | Re: Some serious issues with the new -O option |
Date: | Tue, 30 Apr 2013 11:01:44 +0100 |
Regards,I'm guessing here but I imagine the main problem comes with delaying the results of submakes?I haven't tested to see if this is how the new feature works or not. I don't think it's completely necessary to keep all output from one submake together. so turning that off might make things more interactive, Per-target syncing is a valid compromise.
Tim--On 30 April 2013 10:48, Stefano Lattarini <address@hidden> wrote:
I'm sorry to say that the new -O option can interact *badly*
with Automake-generated parallel testsuites (at least when they
are being run "interactively", that is, with the output of make
connected to a tty).
Let me elaborate a little (if you still have doubts or objections
after reading the considerations below, please do not hesitate to
ask for clarifications).
For long-running testsuite with lots of tests, the use of the '-O'
option prevents the results from the tests already run to be displayed
on the screen until the *whole* testsuite has run. IMO, this destroys
feedback and readability of the output. Try building GNU coreutils and
running its testsuite with "make -j2 -O" on a slowish system to see how
this can be annoying in practice.
Moreover, since the output of the recipes is no longer connected to
a terminal, automatic colorization of output no longer work: no more
good results in green and failures in red (unless the user forces
them by exporting AM_COLOR_TESTS to "always").
In defense of the '-O' option, I must say that I see how such an option
can be actually useful to produce more readable logs when the output is
being redirected to a file (so that one doesn't care about real-time
feedback on the console); but for most "interactive" usages, I believe
its downsides definitely overweight its advantages.
So please don't ever make that option the default; if you really really
want to, at least put in place some smart checks that only enable '-O'
when the output is *not* a tty, so that we can have the best of both
worlds (useful feedback for interactive runs, more readable logs for
batch runs).
Thanks,
Stefano
_______________________________________________
Bug-make mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-make
You could help some brave and decent people to have access to uncensored news by making a donation at:
http://www.thezimbabwean.co.uk/friends/
[Prev in Thread] | Current Thread | [Next in Thread] |