After reading It’s Time To Do CMake Right and The Ultimate Guide to Modern CMake I stumbled about the slides of Effective CMake by Daniel Pfeifer. (I did not watch the related video C++Now 2017: Daniel Pfeifer “Effective CMake” though.)
What attracted my attention where the commands
ctest_memcheck() from the slide about CTest which comes with CMake and which I already use. In libcgi and some non free projects I create additional tests to be run with valgrind if that tool is found on the build host, but when using CTest/CDash I don’t need to do that and also get coverage tests on top, so I set up a local CDash server on my workstation, which was painful in multiple ways.
After extracting the CDash archive and configuring lighttpd to server its PHP files the install.php came back with the following error message:
Specified key was too long; max key length is 767 bytes
It was not easy to find the cause. The web says this is fixed in MariaDB 10.2.x while my Debian stable still has 10.1.x … and I found only some workarounds on that problem for other projects than CDash. I could “solve” that by changing the database collation from utf8mb4_unicode_ci to utf8_unicode_ci in phpMyAdmin on the still empty database cdash before running
The more challenging problem was to actually submit results to the CDash server when calling CTest. The webserver always responded with HTTP Status Code 417. That was only partly fault of CDash, which seems to call curl with some strange (?) headers for submission. That turned out to trigger some (from my side) unexpected behavior in lighttpd, for which several tickets exist, I found #1017 eventually, which led me to the lighttpd 1.4.21 release info giving the hint I needed. I added this somewhere in my lighttpd config files:
server.reject-expect-100-with-417 = "disable"
In the end I have a local CDash instance now and could already submit some helpful coverage and memcheck results. Best thing: This way I can remove the error prone additional tests from my
CMakeLists.txt and still run the tests with valgrind, even more flexible than ever.