OK so I ended up doing the following : Use a cmake script to detect coverage support and set up a new build type + Let CTest run GCov for me
Final result can be seen here : https://github.com/Lectem/cpp-boilerplate link to the Coverage setup script : https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/Coverage.cmake This seems to be the best way to do it, it is non-intrusive (no CMAKE_<LANG>_FLAGS clobbering), plus it really does check that it is supported by the compiler, not assuming versions or anything. If the user wants to build with coverage support, he only needs to use the Coverage build type, and can change the flags from the cache if needed, just as he would do with any build type. Also not that since the codecov.io script runs GCov by default, using CTest is facultative. (but you need to make sure the gcov version matches the compiler used). De : Konstantin Tokarev Envoyé le :lundi 7 août 2017 19:52 À : Clément Gregoire; Rolf Eike Beer Cc : Cmake Mailing List Objet :Re: [CMake] Coverage support 07.08.2017, 20:50, "Clément Gregoire" <lec...@gmail.com>: This is mainly why I started this thread, I want to know the best way to do this without using those variables. CMAKE_lang_FLAGS is a pain as soon as someone wants to use add_subdirectory (be it to add an external project or your project being used in another) or a user wants to change the value. Those variables should really only be set by the toolchain file or from the command-line. There's ExternalProject for this purpose Other solutions were mentioned in my first mail, the easiest one being to add a new build type. The other option is to uses something like a special script that will set those variables before your Cmakelists.txt (ie a toolchain file). Le lun. 7 août 2017 à 17:22, Konstantin Tokarev <annu...@yandex.ru> a écrit : 07.08.2017, 17:24, "Clément Gregoire" <lec...@gmail.com>: >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> >> The pthread thing there is likely wrong anyway, and the -Wall is entirely >> optional. The other things are needed, otherwise gcov will not produce any >> useful output. > > I don't have an issue with the flags per se, but with the usage of > set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern > cmake scripts. How can one set global compiler flags without use of CMAKE_CXX_FLAGS or setting flags for each individual target? > >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> >> No, you don't. It's entirely fine if you just run "make test" as I do in >> OSM2go. > From what I saw in the documentation of the script : > >> # Param _testrunner The name of the target which runs the tests > > It seems to call directly the command named _testrunner, which is somehow > confirmed from the cmakelists : > >> # src/CMakelists.txt >> add_executable(tests ${TEST_FILES}) >> >> # Linking up all libraries >> >> target_link_libraries(tests complex) >> >> add_test(NAME example_test COMMAND tests) >> # CMakelists.txt >> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage) > From this I deduce that you need to call setup_target_for_coverage for each > different test executable. > > 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer <e...@sf-mail.de>: >> Am 2017-08-07 11:06, schrieb Clément Gregoire: >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> >> The pthread thing there is likely wrong anyway, and the -Wall is entirely >> optional. The other things are needed, otherwise gcov will not produce any >> useful output. >> >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> >> No, you don't. It's entirely fine if you just run "make test" as I do in >> OSM2go. >> >> Eike >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin -- Regards, Konstantin
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
