[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autotest: enable colored test results.

From: Ralf Wildenhues
Subject: Re: Autotest: enable colored test results.
Date: Tue, 15 Jun 2010 21:21:38 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

[ dropping bug-coreutils, this mail doesn't address that question ]

* Eric Blake wrote on Mon, Jun 14, 2010 at 10:23:51PM CEST:
> On 06/14/2010 01:45 PM, Ralf Wildenhues wrote:
> > * Eric Blake wrote on Mon, Jun 14, 2010 at 07:22:31PM CEST:
> >> Did you make sure that AT_COLOR_TESTS can be specified either side of
> >> AT_INIT, or is there a fixed invocation order that authors must be aware 
> >> of?
> > 
> > Right now it has to be specified before AT_INIT.  If there's a diversion
> > thinhy we can easily fix that with, great, otherwise I guess it would
> > need documentation and order warning in the code.  Help?
> It seems like it would merely be a matter of unconditionally emitting
> at_color=no in an early diversion, and having AT_COLOR_TESTS emit
> at_color=auto in an intermediate diversion, all before the option
> parsing that appears in a later diversion.  That way, if the user didn't
> specify --color, they pick up the appropriate default.
> That also implies that anything else that checks at m4-time whether
> AT_color is defined (such as your m4_ifdef for changing the --help
> output text) must be m4_wrap'd to delay any output based on that
> decision of AT_color until after the user's source file has been
> completely read in.  Then again, we already m4_wrap some of our --help
> text in order to accurately tell the user how many AT_SETUPs we
> encountered, so this may already be taken care of given the current
> architecture of autotest.

I think I got that working now, incremental patch below and full one
attached.  It wasn't even necessary to output at_color initialization
more than once.

One problem I see with this change is that the code documents

  #    Tuning help text.  Additional tuning options can be appended as
  #    self-contained cat'd here-docs as generated by AS_HELP_STRING.

so when we now use m4_wrap, tuning help from the user will get added
before our own, right?  So this is at least a semantic change.  FWIW,
I haven't found instances of HELP_TUNING in an online code search.

Add another diversion HELP_TUNING_BASE and let HELP_TUNING be for the


diff --git a/lib/autotest/general.m4 b/lib/autotest/general.m4
index c2fc369..23bf145 100644
--- a/lib/autotest/general.m4
+++ b/lib/autotest/general.m4
@@ -389,8 +389,6 @@ at_jobs=1
-# Whether to enable colored test results.
-at_color=m4_ifdef([AT_color], [AT_color], [no])
 # Shall we keep the debug scripts?  Must be `:' when the suite is
 # run by a debug script, so that the script doesn't remove itself.
@@ -425,6 +423,8 @@ m4_define([_AT_FINISH],
 [m4_ifdef([AT_ingroup], [m4_fatal([missing AT_CLEANUP detected])])dnl
+# Whether to enable colored test results.
+at_color=m4_ifdef([AT_color], [AT_color], [no])
 # List of the tested programs.
   [m4_translit(m4_dquote(m4_defn([AT_tested])), [ ], m4_newline)])'
@@ -721,7 +721,7 @@ Operation modes:
   -l, --list     describes all the tests, or the selected TESTS
 cat <<_ATEOF || at_write_fail=1
 dnl extra quoting prevents emacs whitespace mode from putting tabs in output
@@ -745,7 +745,7 @@ Execution tuning:
 [                 default for debugging scripts]
   -x, --trace    enable tests shell tracing
 cat <<_ATEOF || at_write_fail=1

Attachment: color.diff
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]