Coverage support

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Coverage support

Lectem
Hi,
I'm a bit stuck when trying to add coverage reports to Cmake (gcov + lcov) as I can't figure out what is the best (idiomatic) way to do it.
So far here are the ways I know of :
- setting the CMAKE_LANG_FLAGS based on a boolean + scan all files / run gcov on it : would like to avoid this
- same but adding a new build type : seems to be way better but running gcov would still be a pain
- same with a tool chain file for the flags : doesn't sound a good idea since coverage should only be ran in debug
- some library to link with that propagates the flags : not possible because link flags are not transient
- macro that adds the flags / does magic on a per target basis : many scripts do this but seems to be a pain to maintain. Also I would rather have all my test targets be set up automatically
- any of the above for flags and Ctest ctest_coverage but all I need are the gcov/lcov reports, not the coverage.xml for the dashboard
- using the command parameter of add_test
- something I missed?

I want the setup to be easy and compatible with codecov.io, sadly all the script I found are bad, undocumented, or old and using bad practices.

Any help is welcome!

Thanks

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Coverage support

Rolf Eike Beer
Am 2017-08-07 09:57, schrieb Clément Gregoire:

> Hi,
> I'm a bit stuck when trying to add coverage reports to Cmake (gcov +
> lcov)
> as I can't figure out what is the best (idiomatic) way to do it.
> So far here are the ways I know of :
> - setting the CMAKE_LANG_FLAGS based on a boolean + scan all files /
> run
> gcov on it : would like to avoid this
> - same but adding a new build type : seems to be way better but running
> gcov would still be a pain
> - same with a tool chain file for the flags : doesn't sound a good idea
> since coverage should only be ran in debug
> - some library to link with that propagates the flags : not possible
> because link flags are not transient
> - macro that adds the flags / does magic on a per target basis : many
> scripts do this but seems to be a pain to maintain. Also I would rather
> have all my test targets be set up automatically
> - any of the above for flags and Ctest ctest_coverage but all I need
> are
> the gcov/lcov reports, not the coverage.xml for the dashboard
> - using the command parameter of add_test
> - something I missed?
>
> I want the setup to be easy and compatible with codecov.io, sadly all
> the
> script I found are bad, undocumented, or old and using bad practices.

What's wrong with this one:
https://github.com/codecov/example-cpp11-cmake ?

I use it for both Codecov.io and CDash at the same time, see
https://github.com/osm2go/osm2go/blob/master/.travis.yml

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
Reply | Threaded
Open this post in threaded view
|

Re: Coverage support

Lectem

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")

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


Le lun. 7 août 2017 à 12:50, Rolf Eike Beer <[hidden email]> a écrit :
Am 2017-08-07 09:57, schrieb Clément Gregoire:
> Hi,
> I'm a bit stuck when trying to add coverage reports to Cmake (gcov +
> lcov)
> as I can't figure out what is the best (idiomatic) way to do it.
> So far here are the ways I know of :
> - setting the CMAKE_LANG_FLAGS based on a boolean + scan all files /
> run
> gcov on it : would like to avoid this
> - same but adding a new build type : seems to be way better but running
> gcov would still be a pain
> - same with a tool chain file for the flags : doesn't sound a good idea
> since coverage should only be ran in debug
> - some library to link with that propagates the flags : not possible
> because link flags are not transient
> - macro that adds the flags / does magic on a per target basis : many
> scripts do this but seems to be a pain to maintain. Also I would rather
> have all my test targets be set up automatically
> - any of the above for flags and Ctest ctest_coverage but all I need
> are
> the gcov/lcov reports, not the coverage.xml for the dashboard
> - using the command parameter of add_test
> - something I missed?
>
> I want the setup to be easy and compatible with codecov.io, sadly all
> the
> script I found are bad, undocumented, or old and using bad practices.

What's wrong with this one:
https://github.com/codecov/example-cpp11-cmake ?

I use it for both Codecov.io and CDash at the same time, see
https://github.com/osm2go/osm2go/blob/master/.travis.yml

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
Reply | Threaded
Open this post in threaded view
|

Re: Coverage support

Rolf Eike Beer
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
Reply | Threaded
Open this post in threaded view
|

Re: Coverage support

Lectem
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.


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 <[hidden email]>:
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
Reply | Threaded
Open this post in threaded view
|

Re: Coverage support

Konstantin Tokarev


07.08.2017, 17:24, "Clément Gregoire" <[hidden email]>:
>> 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 <[hidden email]>:
>> 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
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Coverage support

Lectem

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.

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 <[hidden email]> a écrit :


07.08.2017, 17:24, "Clément Gregoire" <[hidden email]>:
>> 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 <[hidden email]>:
>> 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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Coverage support

Konstantin Tokarev
 
 
07.08.2017, 20:50, "Clément Gregoire" <[hidden email]>:

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 <[hidden email]> a écrit :
 
07.08.2017, 17:24, "Clément Gregoire" <[hidden email]>:
>> 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 <[hidden email]>:
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Coverage support

Lectem

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 : [hidden email]
Envoyé le :lundi 7 août 2017 19:52
À : [hidden email]; [hidden email]
Cc : [hidden email]
Objet :Re: [CMake] Coverage support

 

 

 

07.08.2017, 20:50, "Clément Gregoire" <[hidden email]>:

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 <[hidden email]> a écrit :

 

07.08.2017, 17:24, "Clément Gregoire" <[hidden email]>:
>> 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 <[hidden email]>:
>> 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