2:58 a.m.
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
2:58 a.m.
New subject: [libvirt] [PATCH 1/2] Revert "virt-result.m4: Colourize summary printings"
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
2:58 a.m.
New subject: [libvirt] [PATCH 2/2] Revert "configure: Colorize output"
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
9:18 a.m.
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
12:39 a.m.
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
2060
days inactive
2061
days old
4 comments
2 participants
participants (2)
-
Michal Prívozník -
Peter Krempa