Bruno Haible <br...@clisp.org> writes:

> Hi Simon,
>
>> Ouch.  Shouldn't we rename 'valgrind-tests' instead?
>> ...
>> Whatever problem appears if we rename
>> 'valgrind-tests' to, say, 'valgrindtests' we could fix.
>
> 'valgrindtests' would be a hack.
How so?  The old name was a hack because it hijacked the *-tests
namespace to gain those properties, without actually being a self-test.

I think 'valgrindtests' may be a bit more descriptive, and allows us to
write a valgrindtests-tests to actually test that the module is working
(which would be useful -- there has been bugs causing valgrind not to be
used, and since the output is silent you would normally never notice).

> 'valgrind-support-for-tests' would have the same problem.
>
> 'test-support-with-valgrind' would reflect the meaning, but is a bit long.

Maybe 'valgrind-on-selftests'.

However I also realize that the name is quite well established and has
been in the gnulib manual for a long time.  So I suspect renaming it
will just cause more problems than it solves.

https://www.gnu.org/software//gnulib/manual/html_node/Running-self_002dtests-under-valgrind.html

>> The naming was a clever hack long time ago
>
> What did this naming attempt to achieve?

I must admit I do not remember fully, but I recall it had something to
do with how gnulib-tool automatically added modules and its
makefile/autoconf snippets to the standard invocation process by
default, and there wasn't a simple way to achieve that except by naming
the module *-tests.  All of that now feels more like a problem than a
feature though.

If actual problems appears in the future, we can revisit this, looking
back at this thread.

/Simon

Attachment: signature.asc
Description: PGP signature

Reply via email to