| Message ID | 20210118062501.27022-3-maxim.cournoyer@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Improvements to the Automake SRFI 64 test driver. | expand |
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > The Automake parallel test harness does its own smart detection of the > terminal color capability and always provides the --color-tests argument to > the driver. This change defaults the --color-tests argument to true when the > test driver is run on its own (not via Automake). > > * build-aux/test-driver.scm (main): Set the default value of the --color-tests > argument to true when it's not explicitly provided. It’s a small change to why not, but… … the test driver is not meant to be used on its own though, it’s really a test driver for Automake. Plus, in most projects, part of the test environment is defined in ‘Makefile.am’; I wouldn’t want to process bug reports because people thought they could try and run tests without “make check”. Thoughts? As a side note, this test driver is bundled in quite a few Guile packages. Longer-term, it would be nice to consider maintaining it as part of Automake. Now is maybe a good time since there’s on-going maintenance work happening in Autoconf (and soon Automake and Libtool) after a long hiatus. Ludo’.
Hi Ludo, Ludovic Courtès <ludo@gnu.org> writes: > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > >> The Automake parallel test harness does its own smart detection of the >> terminal color capability and always provides the --color-tests argument to >> the driver. This change defaults the --color-tests argument to true when the >> test driver is run on its own (not via Automake). >> >> * build-aux/test-driver.scm (main): Set the default value of the --color-tests >> argument to true when it's not explicitly provided. > > It’s a small change to why not, but… > > … the test driver is not meant to be used on its own though, it’s really > a test driver for Automake. The interface via make is not terribly convenient/discoverable; I find having the test-driver produce useful output on its own handy for hacking on the thing hands on. > Plus, in most projects, part of the test environment is defined in > ‘Makefile.am’; I wouldn’t want to process bug reports because people > thought they could try and run tests without “make check”. The use of the test driver without the Automake build system is undocumented; I wouldn't be too worried about people suddenly stumbling on it. Thanks, Maxim
diff --git a/build-aux/test-driver.scm b/build-aux/test-driver.scm index 5891631da6..767a9fb25d 100644 --- a/build-aux/test-driver.scm +++ b/build-aux/test-driver.scm @@ -163,14 +163,17 @@ void port, which means no TRS output is logged." (let ((log (and=> (option 'log-file #f) (cut open-file <> "w0"))) (trs (and=> (option 'trs-file #f) (cut open-file <> "wl"))) (out (duplicate-port (current-output-port) "wl")) - (test-name (option 'test-name #f))) + (test-name (option 'test-name #f)) + (color-tests (if (assoc 'color-tests opts) + (option->boolean opts 'color-tests) + #t))) (when log (redirect-port log (current-output-port)) (redirect-port log (current-warning-port)) (redirect-port log (current-error-port))) (test-with-runner (test-runner-gnu test-name - #:color? (option->boolean opts 'color-tests) + #:color? color-tests #:brief? (option->boolean opts 'brief) #:out-port out #:trs-port trs) (load-from-path test-name))