summaryrefslogtreecommitdiff
path: root/test/TEST-09-ISSUE-2691
diff options
context:
space:
mode:
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2023-02-21 19:59:57 +0100
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2023-02-22 11:39:44 +0100
commit50b35193ec6f8f342364742a69a607e967b39b7f (patch)
tree3a87221efb9d6eec7e5d64d4dbc8aeaaa9176e53 /test/TEST-09-ISSUE-2691
parent3f275dcb841bac7a29bba31c3b8b32981f6281fc (diff)
downloadsystemd-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