Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lcov targets fail with Ninja #29

Open
giacomini opened this issue Jun 17, 2020 · 3 comments
Open

lcov targets fail with Ninja #29

giacomini opened this issue Jun 17, 2020 · 3 comments

Comments

@giacomini
Copy link

The same example provided in issue #6 shows that also the support for lcov is failing when using the Ninja generator.

$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON ..
$ ninja -v foo
[1/2] /usr/bin/c++    -g    -O0 -g -fprofile-arcs -ftest-coverage -MD -MT CMakeFiles/foo.dir/test.cc.o -MF CMakeFiles/foo.dir/test.cc.o.d -o CMakeFiles/foo.dir/test.cc.o -c ../test.cc
[2/2] : && /usr/bin/c++  -g  -O0 -g -fprofile-arcs -ftest-coverage CMakeFiles/foo.dir/test.cc.o  -o foo   && :
$ ./foo
Hello World!
$ ninja -v foo-genhtml
[1/8] cd /home/giaco/tmp/lcov-cmake/build && /usr/bin/geninfo --quiet --base-directory /home/giaco/tmp/lcov-cmake --initial --gcov-tool /usr/bin/gcov-7 --output-filename /home/giaco/tmp/lcov-cmake/build/CMakeFiles/foo.dir/test.cc.info.init --no-external /home/giaco/tmp/lcov-cmake/build/CMakeFiles/foo.dir/test.cc.gcno
geninfo: WARNING: could not open /home/giaco/tmp/test.cc
geninfo: WARNING: some exclusion markers may be ignored
[2/8] cd /home/giaco/tmp/lcov-cmake/build && cat /home/giaco/tmp/lcov-cmake/build/CMakeFiles/foo.dir/test.cc.info.init > /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info.raw
[3/8] cd /home/giaco/tmp/lcov-cmake/build && /usr/bin/lcov --quiet -a /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info.raw --output-file /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --base-directory /home/giaco/tmp/lcov-cmake --initial && /usr/bin/lcov --quiet -r /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --output-file /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --initial
FAILED: lcov/data/init/foo.info 
cd /home/giaco/tmp/lcov-cmake/build && /usr/bin/lcov --quiet -a /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info.raw --output-file /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --base-directory /home/giaco/tmp/lcov-cmake --initial && /usr/bin/lcov --quiet -r /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --output-file /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --initial
lcov: ERROR: no valid records found in tracefile /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info.raw
ninja: build stopped: subcommand failed.

At least the first error (geninfo: WARNING: could not open /home/giaco/tmp/test.cc) can be fixed passing ${CMAKE_BINARY_DIR} instead of ${CMAKE_SOURCE_DIR} to the --base-directory option of geninfo. This because Ninja works with paths relative to the binary directory.

Everything works fine with the Makefile generator, which works with absolute paths.

@alehaa
Copy link
Contributor

alehaa commented Jun 23, 2020

Could you provide a patch for this issue? I can reproduce the issue, but unfortunately I'm not familiar with ninja.

@giacomini
Copy link
Author

Me neither :-) but I'll try. Give me a few days.

@Twon
Copy link
Contributor

Twon commented Apr 12, 2021

There a number of potential issues with using the CMake-codecov library with Ninja in its current form which you might be encountering. The first is that when you perform in source builds with Ninja via CMake even if you pass paths in absolute form Ninja will convert them to relative form (this is a problem because the library in its current form generated GCov information with relative paths), see details here: https://gitlab.kitware.com/cmake/cmake/-/issues/13894

Craig Scott proposed the correct solution here: https://gitlab.kitware.com/cmake/cmake/-/issues/20001. That is the Gcc supports a flag, -fprofile-abs-path, which ensures that coverage information stores absolute paths in the resulting *.gcno & *.gcda file. See the details of this flag here: https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Instrumentation-Options.html. This can be tested for and appended to the current coverage flags by testing for support first as is already done within the library:

            set(__coverageFlags --coverage)
            check_cxx_compiler_flag(-fprofile-abs-path HAVE_fprofile_abs_path)
            if(HAVE_fprofile_abs_path)
                list(APPEND __coverageFlags -fprofile-abs-path)
            endif()

The next potential issue and the one it looks like you are encountering here is that geninfo will only generate info for files from the *.gcda files that it finds in the path of the --base-directory passed in when invoking geninfo. The geninfo documentation explicitly mentions this scenario in its documentation and say if this happens to just call geninfo multiple times (with the --ignore-errors flag to silence errors) with different base directories and then to combine using the -a (I assume though it does not say that this part means when calling the lcov executable to append info). One common scenario this happens (and the one I ran into) is where the project created generated files which are written to the binary directory, in which case geninfo must be called again with the binary directory in the --base-directory flag to extract coverage information for generated source files.

If any of this is not clear or you have questions then let me know. It would be great to see these issues resolved in the library.

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

No branches or pull requests

3 participants