Bruno Haible wrote:
>> Not having to worry about cleaning up temporary files
>> and not having to choose "parallel-safe" names for them
>> leads to much cleaner tests.
>> Not having to add signal handlers in every single one
>> avoids duplication and would make them robust by default.
>>
>> IMHO, all new tests should use init.sh, but we haven't
>> discussed whether this should be policy.
>
> You do have a point about tests which create files.
Hi Bruno,
That was my intended point.
For tests that do not create files and do not otherwise
modify the system (and hence do not require clean-up),
using init.sh would be pointless.
> But there are many
> more tests which don't fiddle with files. Let's take test-strncat.c as
> an example.
>
> An extra test-strncat.sh would mean
> 1) Extra files to distribute and to mention in the module description.
> 2) An extra indirection to consider when you want to debug a test failure
> with gdb.
>
> On the positive side: What would be the benefit?
> - Last time you mentioned [1]: Interoperation with automake's parallel tests
> mode. Nothing needs to be done for this; test-strncat.c works perfectly
> fine with parallel-tests already now.
> There is a nit that skipped tests, by gnulib conventions, print a reason
> why the test is skipped, whereas parallel-tests hides this output. But IMO
> this needs to be fixed on Automake's side.
> parallel-tests offers the possibility to have verbose output be emitted
> by the tests. This can be done through printf(), simply, optionally
> wrapped
> in some macros defined in tests/macros.h.
> - You mention signal handlers. But what's the difference? init.sh ensures
> an exit code of 128+sig when signal sig has been caught. But that's
> already the default for C programs.
> - There is also MALLOC_PERTURB_. This can be set in TESTS_ENVIRONMENT
> globally, or in a utility function called from main().
>
> In summary, a shell wrapper for such tests is overkill. All extra
> functionality
> can be done and is better done in C, possibly through function call
> test_init();
> at the beginning of main(). I suggest to put these into tests/macros.h and
> tests/init.c, if we find such functionality is needed.
No argument here :-)
However, on the question of making it easier to wrap a test
with init.sh, I'd like to make it easier.
---------------------------------------------
Currently I've been creating a tiny script like this for each
program I want to wrap, git-adding it, and listing it in Files:, too.
Taking test-areadlink-with-size as an example,
#!/bin/sh
. "${srcdir=.}/init.sh"; path_prepend_ .
test-areadlink-with-size
Exit $?
----------------------------------
Obviously, that can be automated.
I'm thinking of adding something like this for use
in any module that uses init.sh as a trivial wrapper:
GL_emit_init_sh_wrapper = \
t=`echo $@|sed 's,.*/,,;s/\.sh$$//'`; \
printf '%s\n' \
'#!/bin/sh' \
'. "$${srcdir=.}/init.sh"; path_prepend_ .' \
"$$t"'; Exit $$?' > $...@-t && chmod a+x $...@-t && mv $...@-t $@
Then, an individual module file could add these lines:
CLEANFILES += test-areadlink-with-size.sh
test-areadlink-with-size.sh:
$(GL_emit_init_sh_wrapper)
and make this additional change:
(while also adding tests/init.sh to Files:)
-TESTS += test-areadlinkat-with-size
+TESTS += test-areadlinkat-with-size.sh
What do you think of adding the definition of GL_emit_init_sh_wrapper
at the top of each gnulib.mk file? Or maybe only in projects that use
tests/init.sh?
