Skip to content

Conversation

julienmalik
Copy link
Collaborator

Since cmake >= 3.0, using CTEST_USE_LAUNCHERS requires include(CTestUseLaunchers),
which is automatically done by include(CTest)

Setting CTEST_USE_LAUNCHERS in the cache without including CTest later
triggers a configuration error :
CMake Error: CTEST_USE_LAUNCHERS is enabled, but the RULE_LAUNCH_COMPILE
global property is not defined.
Did you forget to include(CTest) in the toplevel CMakeLists.txt ?

CTEST_USE_LAUNCHERS was silently ignored in cmake <= 2.8 when not including CTest

Include CTestUseLaunchers always, so that CTEST_USE_LAUNCHERS can be used even when not
including CTest (for example for MinGW builds).
This helps presenting the build errors and warnings more cleanly on the Dashboard.

Since cmake >= 3.0, using CTEST_USE_LAUNCHERS requires include(CTestUseLaunchers),
which is automatically done by include(CTest)

Setting CTEST_USE_LAUNCHERS in the cache without including CTest later
triggers a configuration error :
   CMake Error: CTEST_USE_LAUNCHERS is enabled, but the RULE_LAUNCH_COMPILE
   global property is not defined.
   Did you forget to include(CTest) in the toplevel CMakeLists.txt ?

CTEST_USE_LAUNCHERS was silently ignored in cmake <= 2.8 when not including CTest

Include CTestUseLaunchers always, so that CTEST_USE_LAUNCHERS can be used even when not
including CTest (for example for MinGW builds).
This helps presenting the build errors and warnings more cleanly on the Dashboard.
@julienmalik
Copy link
Collaborator Author

Hum... quite strange that the mingw warnings disappear with ctest launchers enabled. This should be investigated further.

@julienmalik
Copy link
Collaborator Author

CTEST_USE_LAUNCHERS is even ignored for this mingw build since it uses ctest 2.8, which ignores CTEST_USE_LAUNCHERS since include(CTest) is not used. We need cmake >= 3.0 here

@julienmalik
Copy link
Collaborator Author

With cmake 3.5 it gets better : http://my.cdash.org/viewBuildError.php?type=1&buildid=953977
The warnings are caught and the dashboard report is clear.

@julienmalik
Copy link
Collaborator Author

@mayeut ok for merging ?

might want to still have a cmake 2.8 build around though (I see that appveyor also uses cmake 3.5)...

@mayeut
Copy link
Collaborator

mayeut commented May 3, 2016

@julienmalik,

If I understand correctly, there's no more build using cmake 2.8.x.

find . -name 'CMakeLists.txt' -exec grep 'cmake_minimum_required' {} + outputs the following:

./CMakeLists.txt:cmake_minimum_required(VERSION 2.8.2)
./tests/nonregression/CMakeLists.txt:cmake_minimum_required(VERSION 2.8.7)
./thirdparty/libtiff/CMakeLists.txt:cmake_minimum_required(VERSION 2.6)
./thirdparty/libz/CMakeLists.txt:cmake_minimum_required(VERSION 2.6)

It would be good to keep at least one building with cmake 2.8.x. (e.g. I used a feature from cmake 3.x in a PR and didn't realize it until CI checks failed).
I run tests using cmake 2.8.7 once in a while but not frequently enough to assess anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants