diff options
author | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2023-02-21 19:59:57 +0100 |
---|---|---|
committer | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2023-02-22 11:39:44 +0100 |
commit | 50b35193ec6f8f342364742a69a607e967b39b7f (patch) | |
tree | 3a87221efb9d6eec7e5d64d4dbc8aeaaa9176e53 /test/TEST-09-ISSUE-2691 | |
parent | 3f275dcb841bac7a29bba31c3b8b32981f6281fc (diff) | |
download | systemd-50b35193ec6f8f342364742a69a607e967b39b7f.tar.gz |
meson: merge our two valgrind configuration conditions into one
Most of the support for valgrind was under HAVE_VALGRIND_VALGRIND_H, i.e. we
would enable if the valgrind headers were found. The operations then we be
conditionalized on RUNNING_UNDER_VALGRIND.
But in a few places we had code which was conditionalized on VALGRIND, i.e. the
config option. I noticed because I compiled with -Dvalgrind=true on a machine
that didn't have valgrind.h, and the build failed because
RUNNING_UNDER_VALGRIND was not defined. My first idea was to add a check that
the header is present if the option is set, but it seems better to just remove
the option. The code to support valgrind is trivial, and if we're
!RUNNING_UNDER_VALGRIND, it has negligible cost. And the case of running under
valgrind is always some special testing/debugging mode, so we should just do
those extra steps to make valgrind output cleaner. Removing the option makes
things simpler and we don't have to think if something should be covered by the
one or the other configuration bit.
I had a vague recollection that in some places we used -Dvalgrind=true not
for valgrind support, but to enable additional cleanup under other sanitizers.
But that code would fail to build without the valgrind headers anyway, so
I'm not sure if that was still used. If there are uses like that, we can
extend the condition for cleanup_pools().
Diffstat (limited to 'test/TEST-09-ISSUE-2691')
0 files changed, 0 insertions, 0 deletions