[gnutls-devel] valgrind-tests vs full-test-suite

[Alon Bar-Lev]

On 14 March 2017 at 09:36, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Mon, Mar 13, 2017 at 6:49 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> Hi,
>>
>> I believe this is the last issue in tests of gnutls-3.5... :)
>>
>> I started stabilization process in Gentoo, it will be nice if we can
>> solve this nicely as well.
>>
>> Look at this full-test-suite[1] conditional:
>> ---
>> # test if we are in git master or in release build. In release
>> # builds we do not use valgrind.
>> SUITE_FILE="${srcdir}/tests/suite/mini-eagain2.c"
>> if test "$full_test_suite" = yes && test ! -f "$SUITE_FILE";then
>>     full_test_suite=no
>>     VALGRIND=""
>>     AC_SUBST(VALGRIND, [])
>>     opt_valgrind_tests=no
>> fi
>> ---
>>
>> This actually disables valgrind in non-git but I do not see any reason
>> to do so as valgrind is supported in some other tests. If I disable
>> the full-tests-suite then I can enjoy valgrind extra tests.
>> Any reason why we condition this?
>
> If I remember well, the reason this was introduced was to avoid test
> suite failures due to leaks or other issues in unrelated libraries on
> the released version. E.g., if you try to compile the latest release
> of gnutls in a system which has a libc with a leak, you wouldn't have
> the test suite fail because of that.

The valgrind tests may be enabled or disabled.
In release tarball there is no full-suite.
The result is that valgrind cannot be enabled unless the non-existence
full-suite is disabled...
So I do not think this logic is required.