Relative vs. absolute include paths and gcov
The GNU code coverage tool gcov
has a flag -r
for filtering include files to process by whether the include path is relative or absolute.
https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html
However, CMake seems to give no control over whether the include path is relative or absolute. For example, consider the following:
include_directories(
.
${PROJECT_SOURCE_DIR}/ext
)
This will produce gcc
compiler statements that are different depending on the build system. With Unix Makefiles, it does:
/usr/bin/c++ -I/home/user/project/src/. -I/home/user/project/ext
This renders the -r
gcov flag useless since all include paths are now absolute.
With ninja, it does:
/usr/bin/c++ -I../src/. -I../ext
This is a little better, since gcov -r
now ignores system includes, but it's still going into ext/
which I would prefer it not do since that directory contains a bunch of 3rd party code from GitHub and the like. It would be nice if CMake gave finer control over whether an include path was relative or absolute.
For example:
include_directories(
. #relative - produces -I../src/.
${CMAKE_CURRENT_SOURCE_DIR} #absolute - produces -I/home/user/project/src
${CMAKE_CURRENT_SOURCE_DIR_REL} #relative - produces -I../src/.
${PROJECT_SOURCE_DIR}/ext #absolute - produces -I/home/user/project/ext
${PROJECT_SOURCE_DIR_REL}/ext #relative - produces -I../ext
../ext #relative - produces -I../ext
)
Thoughts?
Might be somewhat related to #13894 (closed) but in this context I only care about header include paths because that's what gcov is crawling when I feed it a given source's gcno
and gcda
files. Having the -r
flag fully functional speeds up coverage processing time by an order of magnitude.