Make building against Valgrind headers optional

[thesamesam]

Valgrind isn't available on all (really, most) arches, but also, even those on supported arches may not love installing Valgrind purely for the headers if it won't ever be used at runtime (e.g. on an AVX512 machine any time soon...).

At https://github.com/oracle/dtrace-utils/blob/devel/libdtrace/dt_work.c#L22, we include <valgrind/valgrind.h> unconditionally.

This came up downstream at https://bugs.gentoo.org/938190 where I wrongly removed the DEPEND on Valgrind because I grepped badly.

[kvanhees]

I think we can go two ways:

1. introduce an option to select whether building with valgrind support or not
2. automatically build with valgrind support if the needed header file is present

I am inclined to go with 2. simply because it is easier and harmless, and 1. still would require a test that the header is actually present (rather than just letting the build).

Thoughts?

[thesamesam]

I almost agree with 2, the problem is you get a non-deterministic build depending on whether Valgrind was installed when you built DTrace...

[thesamesam]

Another option is we use a bundled header or inline the relevant macros as a fallback. This came up in GCC and the conclusion was "Valgrind is very unlikely to change its interface".

[nickalcock]

Honestly, I'm astonished I'm not already using a header guard. IMHO, we should obviously only be including <valgrind/valgrind.h> if it exists, we should obviously be trying to use it if present by default but not failing by default if absent, and we should obviously have a configure option to force-require its presence, just as with other optional features (and "cooperate when running under valgrind" presumably counts as one of those).