On Thursday 16 June 2011, Stefano Lattarini wrote:
> This refactoring should cause no API of functionality change,
> and is meant only to simplify the future implementation of TAP
> and SubUnit testsuite drivers. More precisely, our roadmap is
> to move most of the "testsuite driving" features out of the
> Automake-generated Makefiles, and into external scripts with
> well-defined interfaces. This will allow the user to define
> its own personalized testsuite drivers, and will also offer us
> a framework upon which to implement our new TAP and SubUnit
> drivers, all in a very unobtrusive way and retaining an high
> degree of code reuse and backward-compatibility.
>
The NEWS entry wasn't descriptive enough, as the problems with the
coreutils's testsuite have showed. I've squashed this is (which
also fixes a couple of typos in the process):
diff --git a/NEWS b/NEWS
index 7930135..394f6b2 100644
--- a/NEWS
+++ b/NEWS
@@ -16,9 +16,16 @@ New in 1.11a:
- The parallel-tests driver is now implemented (partly at least) with
the help of automake-provided auxiliary scripts (e.g., `test-driver'),
instead of relying entirely on code in the generated Makefile.in.
- This implies that project using the `parallel-tests' option should
- now wither run automake with the `--add-missing' option, or manually
- copy the `test-driver' script into their tree.
+ This has two noteworthy implications. The first one is that projects
+ using the `parallel-tests' option should now either run automake with
+ the `--add-missing' option, or manually copy the `test-driver' script
+ into their tree. The second, and more important, implication is that
+ now shell functions and non-environmental shell variables defined in
+ TESTS_ENVIRONMENT are not anymore available in LOG_COMPILER and
+ <ext>_LOG_COMPILER. For example, it is now no more possible to define
+ a shell function, say `custom_test_runner', in TESTS_ENVIRONMENT, and
+ then setting "LOG_COMPILER = custom_test_runner" in the Makefile.am in
+ oder to use that function to run the tests.
* WARNING: Future backward-incompatibilities!
An update to the documentation is also in order IMHO, but I'd rather
keep that for a follow-up patch.
Regards,
Stefano
