I just updated ninja version 1.5.3 -> 1.8.2 on dash5 (osx build machine for continuous integration testing). As the version was so old that might just be the reason for those frequent GTest timeouts. Let’s wait and see.
1 Like
Sounds promising. Let us know when there is some proof that this fixes the timeout issues we’ve been witnessing lately. Thanks @dzenanz
It should have already been noticeable, but it looks like that didn’t help much.
I am having a similar failure on the SimpleITK dashboard:
https://open.cdash.org/viewBuildError.php?buildid=5458556
The failure is related to a GTest, which uses CMake’s build time detection of GTest in a driver.
The system is running CMake 3.11.1, and just using the system GNU Makefile generator.
It appears to have begun failing on July 16.
A quick check of my failure showed that it took a really long time to link the offending executable.
The command line also revealed a variable pass “-D TEST_DISCOVERY_TIMEOUT=5”.
Does the ITK problematic executable take a long time to link? Does the executable need to be split in twine? Can we set this time out in cmake?
Here is a proposed patch which lengths the GTest discover timeout:
http://review.source.kitware.com/#/c/23608/
The DISCOVERY_TIMEOUT option was added in CMake 3.10, perhaps the default of 5 seconds is too short:
https://cmake.org/cmake/help/v3.10/module/GoogleTest.html
There is a compatibility issue with CMake 3.10.2:
In CMake versions 3.10.1 and 3.10.2, this option was called TIMEOUT. This clashed with the TIMEOUT test property, which is one of the common properties that would be set with the PROPERTIES keyword, usually leading to legal but unintended behavior. The keyword was changed to DISCOVERY_TIMEOUT in CMake 3.10.3 to address this problem. The ambiguous behavior of the TIMEOUT keyword in 3.10.1 and 3.10.2 has not been preserved.
I guess we are stuck with 3.10.2.