CTest: MemCheck with Valgrind using --xml=yes and --xml-file
The problem
Specifying --xml=yes
option for Valgrind requires also to specify the sink for the produced XML data. Typically with --xml-file=<path>
argument. It would be nice to have something like MemoryChecker.*.xml
file along with the now existing MemoryChecker.*.log
. Alas, it seems not possible with the current implementation!
The MemoryChecker.*.log
seems to be achieved by special code in cmCTestMemCheckHandler.cxx
where MemoryChecker.??.log
is used and the ??
is later replaced by test index. However, this special treatment (for Valgrind) is only available to this single parameter (the --log-file=<path>
).
Workaround (kind of...)
The best what I got was to use --xml=yes --xml-file=<build_dir>/Testing/Temporary/MemoryChecker.%p.xml
where the %p
is interpreted by Valgrind itself and PID is substituted. However, now the developer needs to locate the correct MemoryChecker.*.log
(based on test index), open it and see the PID (which is printed at the start of each line), and only then locate the correct MemoryChecker.*.xml
file. Not so nice.
A better workaround?
Is there any better workaround which would work with CMake 3.13 (or 3.17) and allow to skip this extra "hop" from MemoryChecker.*.log
to MemoryChecker.*.xml
to get the right index?
Possible solutions
Generic placeholder
Let's support the special meaning of ??
for all command-line arguments!
However, if so, then perhaps it would be wiser to have a more unique placeholder? For example, %ctest_test_index%
. It would be reasonable to pick syntax that would be easy to extend for use of other variables.
Environment variable
Valgrind supports more placeholders than just %p
. A notable example is %q{FOO}
which is replaced by the environment variable FOO
.
We could leverage that by defining an environment variable CTEST_TEST_INDEX
for example.
Any interest?
Is there any interest in solving this issue? Which of the two approaches would be preferable? Or both? Or there is some other approach? I could try to implement this but would prefer to know the preferred approach first.