[libvirt] [PATCH 0/2] Don't colorize output senselessly
Basing the colors on the message itself is in many cases wrong. Look into the patches for examples. Peter Krempa (2): Revert "virt-result.m4: Colourize summary printings" Revert "configure: Colorize output" m4/virt-colours.m4 | 62 ---------------------------------------------- m4/virt-result.m4 | 21 +++------------- 2 files changed, 3 insertions(+), 80 deletions(-) delete mode 100644 m4/virt-colours.m4 -- 2.21.0
The colorization based on the string itself makes little to no sense as the semantic meaning of the color (red = bad, green = good) is not extracted from the semantics of the message: 1) If there is some additional string a 'yes' is marked yellow: configure: driver_modules: yes (CFLAGS='' LIBS='-ldl') 2) In some cases a 'no' is actually good: configure: hal: no 3) Few good/recommended configuration options are still yellow: configure: QEMU: qemu:qemu while using 'root:root' would still be yellow. 4) fields dumping config (e.g. the warning flags line) is a giant blob of colored text which makes little sense configure: Warning Flags: -fno-common -W -Wabsolute-value -Waddress -Waddress-of-packed-member -Waggressive-loop-optimizations -Wall -Wattribute-warning -Wattributes -Wbad-function-cast -Wbool-compare -Wbool-operation -Wbuiltin-declaration-mismatch -Wbuiltin-macro-redefined -Wcannot-profile -Wcast-align -Wcast-align=strict -Wcast-function-type -Wchar-subscripts -Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch -Wcpp -Wdangling-else -Wdate-time -Wdeprecated-declarations -Wdesignated-init -Wdiscarded-array-qualifiers -Wdiscarded-qualifiers -Wdiv-by-zero -Wdouble-promotion -Wduplicated-cond -Wduplicate-decl-speci ... In addition if the idea is to switch to a more usable build system it does not make sense to clutter the current one with more code. This reverts commit 4b3ab5d2135a0dccd654491ef3a4f5b71575deae. --- m4/virt-result.m4 | 21 +++------------------ 1 file changed, 3 insertions(+), 18 deletions(-) diff --git a/m4/virt-result.m4 b/m4/virt-result.m4 index 9115be5774..36973ba0b5 100644 --- a/m4/virt-result.m4 +++ b/m4/virt-result.m4 @@ -31,27 +31,12 @@ dnl eg dnl dnl LIBVIRT_RESULT([yajl], [yes], [-I/opt/yajl/include -lyajl]) dnl - -m4_defun_init([_AS_ECHO_LOG_N], -[AS_REQUIRE([_AS_LINENO_PREPARE])], -[_AS_ECHO_N([$as_me:${as_lineno-$LINENO}: $1], AS_MESSAGE_LOG_FD)]) - -m4_defun_init([AS_MESSAGE_N], -[AS_REQUIRE([_AS_ME_PREPARE])], -[m4_ifval(AS_MESSAGE_LOG_FD, - [{ _AS_ECHO_LOG_N([$1]) -_AS_ECHO_N([$as_me: $1], [$2]);}], - [_AS_ECHO_N([$as_me: $1], [$2])])[]]) - AC_DEFUN([LIBVIRT_RESULT], [ - STR=`printf "%20s: " "$1"` if test "$2" = "no" || test -z "$3" ; then - VAL=`printf "%s" "$2"` + STR=`printf "%20s: %s" "$1" "$2"` else - VAL=`printf "%s (%s)" "$2" "$3"` + STR=`printf "%20s: %s (%s)" "$1" "$2" "$3"` fi - AS_MESSAGE_N([$STR]) - _AS_ECHO([$VAL], AS_MESSAGE_LOG_FD) - COLORIZE_RESULT([$VAL]) + AC_MSG_NOTICE([$STR]) ]) -- 2.21.0
The colors are not based on the semantics of the message but rather on the message itself. This means that the default human-perceived semantics (red = bad, green = good) don't really apply and spotting a color does not mean anythting. This is amplified by the sheer amount of output which configure produces and the fact that some of the messages have negative semantics or additional output. In case of any problem the user will have to go through everything anyways as spotting a red or yellow line has 0 information value. Here are a few examples: 1) some 'no' messages are not a problem: checking minix/config.h presence... no 2) some 'no' messages are actually positive: checking for special C compiler options needed for large files... no 3) in some cases a 'yes' would mean that something is broken or needs workaround checking whether stat file-mode macros are broken... no checking whether wint_t is too small... no checking whether stdint.h predates C++11... no checking whether the inttypes.h PRIxNN macros are broken... no checking whether clang gives bogus warnings for -Wdouble-promotion... no checking whether gettimeofday clobbers localtime buffer... no 4) due to string match based colors extra text makes messages yellow checking for a traditional french locale... none checking for working nanosleep... no (mishandles large arguments) checking for library containing gethostbyname... none required checking whether mbrtowc handles incomplete characters... (cached) guessing yes 5) in some cases the yes/no is very context dependant checking whether pthread_rwlock_rdlock prefers a writer to a reader... no checking whether this build is done by a static analysis tool... no 6) detected paths to binaries and libs are yellow despite being present checking for objdump... objdump checking for atomic ops implementation... gcc As of the reasons above I don't think the colorization of the configure output helps users or developers to debug the build process and thus is not worth the extra code or output clutter. This reverts commit c98174ce087fe23f567292132e961d4685faf337. --- m4/virt-colours.m4 | 62 ---------------------------------------------- 1 file changed, 62 deletions(-) delete mode 100644 m4/virt-colours.m4 diff --git a/m4/virt-colours.m4 b/m4/virt-colours.m4 deleted file mode 100644 index 251778f2ff..0000000000 --- a/m4/virt-colours.m4 +++ /dev/null @@ -1,62 +0,0 @@ -dnl Colourful configure -dnl -dnl Copyright (C) 2015 Nobuyoshi Nakada -dnl -dnl This library is free software; you can redistribute it and/or -dnl modify it under the terms of the GNU Lesser General Public -dnl License as published by the Free Software Foundation; either -dnl version 2.1 of the License, or (at your option) any later version. -dnl -dnl This library is distributed in the hope that it will be useful, -dnl but WITHOUT ANY WARRANTY; without even the implied warranty of -dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -dnl Lesser General Public License for more details. -dnl -dnl You should have received a copy of the GNU Lesser General Public -dnl License along with this library. If not, see -dnl <http://www.gnu.org/licenses/>. - -AC_DEFUN([_COLORIZE_RESULT_PREPARE], [ - msg_checking= msg_result_yes= msg_result_no= msg_result_other= msg_reset= - AS_IF([test -t 1], [ - msg_begin="`tput smso 2>/dev/null`" - AS_CASE(["$msg_begin"], ['@<:@'*m], - [msg_begin="`echo "$msg_begin" | sed ['s/[0-9]*m$//']`" - msg_checking="${msg_begin}33m" - AS_IF([test ${TEST_COLORS:+set}], [ - msg_result_yes=[`expr ":$TEST_COLORS:" : ".*:pass=\([^:]*\):"`] - msg_result_no=[`expr ":$TEST_COLORS:" : ".*:fail=\([^:]*\):"`] - msg_result_other=[`expr ":$TEST_COLORS:" : ".*:skip=\([^:]*\):"`] - ]) - msg_result_yes="${msg_begin}${msg_result_yes:-32;1}m" - msg_result_no="${msg_begin}${msg_result_no:-31;1}m" - msg_result_other="${msg_begin}${msg_result_other:-33;1}m" - msg_reset="${msg_begin}m" - ]) - AS_UNSET(msg_begin) - ]) - AS_REQUIRE_SHELL_FN([colorize_result], - [AS_FUNCTION_DESCRIBE([colorize_result], [MSG], [Colorize result])], - [AS_CASE(["$[]1"], - [yes], [AS_ECHO(["${msg_result_yes}$[]1${msg_reset}]")], - [no], [AS_ECHO(["${msg_result_no}$[]1${msg_reset}]")], - [AS_ECHO(["${msg_result_other}$[]1${msg_reset}]")])]) -]) - -AC_DEFUN([COLORIZE_RESULT], [AC_REQUIRE([_COLORIZE_RESULT_PREPARE])dnl - AS_LITERAL_IF([$1], - [m4_case([$1], - [yes], [AS_ECHO(["${msg_result_yes}$1${msg_reset}"])], - [no], [AS_ECHO(["${msg_result_no}$1${msg_reset}"])], - [AS_ECHO(["${msg_result_other}$1${msg_reset}"])])], - [colorize_result "$1"]) dnl -]) - -AC_DEFUN([AC_CHECKING],[dnl -AC_REQUIRE([_COLORIZE_RESULT_PREPARE])dnl -AS_MESSAGE([checking ${msg_checking}$1${msg_reset}...])]) - -AC_DEFUN([AC_MSG_RESULT], [dnl -{ _AS_ECHO_LOG([result: $1]) -COLORIZE_RESULT([$1]); dnl -}]) -- 2.21.0
On 9/18/19 9:58 AM, Peter Krempa wrote:
Basing the colors on the message itself is in many cases wrong. Look into the patches for examples.
Peter Krempa (2): Revert "virt-result.m4: Colourize summary printings" Revert "configure: Colorize output"
m4/virt-colours.m4 | 62 ---------------------------------------------- m4/virt-result.m4 | 21 +++------------- 2 files changed, 3 insertions(+), 80 deletions(-) delete mode 100644 m4/virt-colours.m4
Looks like this made people more angry than I anticipated. Feel free to revert the patches. ACK Michal
On Wed, Sep 18, 2019 at 16:18:23 +0200, Michal Privoznik wrote:
On 9/18/19 9:58 AM, Peter Krempa wrote:
Basing the colors on the message itself is in many cases wrong. Look into the patches for examples.
Peter Krempa (2): Revert "virt-result.m4: Colourize summary printings" Revert "configure: Colorize output"
m4/virt-colours.m4 | 62 ---------------------------------------------- m4/virt-result.m4 | 21 +++------------- 2 files changed, 3 insertions(+), 80 deletions(-) delete mode 100644 m4/virt-colours.m4
Looks like this made people more angry than I anticipated. Feel free to revert the patches.
I want to emphasise that I don't have problem with using colored text to simplify spotting problems. One example is the colored output of our unit test suite where the usage of colors allows me to find a broken test quickly.
ACK
Michal
participants (2)
-
Michal Prívozník -
Peter Krempa