I am here with the problem, not getting an cpp files in gcovr output. Actually my main project consist of many sub cpp files but, they are located in different directory paths.
Directory layout:
D:\selv_ar\GCovTest\ado\cic\rc_actuator_switch\ulf\src (source directory)
test\devices\puu_driver\sw (main project directory)
core\devices\puu_driver (sub files)
test\testtools (sub files)
test\devices\puu_driver (workspace)
I have a simple hello world program with the files main.cpp, helloworld.h, and helloworld.cpp in the same directory.
Notes:
I am compiling to the embedded target debgcov_qnx660_qcc_x86 and copy the gcda files into the same directory as the source files.
I am running gcovr from the main project directory.
Questions:
When I create a coverage report for the hello world program, why doesn't it show the helloworld.h file?
When I create a coverage report for my actual software, it shows coverage for files in the main project directory. Why doesn't it show coverage for the sub files?
From which directory should I run gcvor? The main directory? The source directory? The workspace?
Where should I put the gcda files? Into the main project directory? Into the sub file directories?
When I create a coverage report for the hello world program, why doesn't it show the helloworld.h file?
Gcovr only reports a file if it contains executable code. Header files usually only contain declarations, but not function definitions. You can check whether that file was seen by running gcovr in `--verbose`` mode.
Some GCC versions have a bug so that files with zero coverage are not reported, even if they contain executable code. See the gcvor FAQ[1] for compiler versions that fix this.
[1]: sorry, the main gcovr.com website is down at the moment.
When I create a coverage report for my actual software, it shows coverage for files in the main project directory. Why doesn't it show coverage for the sub files?
Gcovr tries to filter out coverage data that is irrelevant for your project, for example coverage data for the standard library.
Gcovr only keeps the coverage data if the file path is matched by a -f/--filter.
If no filters are given, the path must be within the -r/--root directory.
If no --root is explicitly provided, the current working directory is used.
So when you run gcovr without arguments like --filter or --root, gcovr will only show coverage for files within the current working directory.
To fix this, give a root path that contains all the directories for which you want coverage, like --root ../ or --root D:/selv_ar/GCovTest/ado/cicrc_actuator_switch/ulf/src.
Or, you can provide filters that match all files where you are interested in coverage. Note that filters are regexes, so you need to escape special characters like .. Also, use forward slashes for paths in the regex. Example in shell syntax:
$ gcovr --root . \
-f 'D:/selv_ar/GCovTest/ado/cicrc_actuator_switch/ulf/src/(test|core)/devices/puu_driver/' \
-f 'D:/selv_ar/GCovTest/ado/cicrc_actuator_switch/ulf/src/test/testtools/'
Make sure that you are using gcovr version 4 or later for filters to work correctly on Windows. If you want to use --root ../ style paths, you should use gcovr 4.2 (not yet released, install the development version from GitHub in the meanwhile).
From which directory should I run gcvor? The main directory? The source directory? The workspace?
Where possible, gcovr should be run in the same directory where GCC runs. This typically means your build directory. If GCC runs in multiple directories, try to use a parent directory of all of these. Use the --root, --filter, and search path arguments to provide suitable paths to the source code and to the gcda files.
Where should I put the gcda files? Into the main project directory? Into the sub file directories?
The .gcda files must be placed next to the corresponding .o object files and .gcno files that the compiler generates. This is important so that the correct source files can be found.
If you're using cross-compilation, collecting coverage data that works can be more complicated. If you encounter problems read about GCOV_PREFIX in the “Cross-Profiling” chapter of the GCC docs and gcovr issue #259.
Gcovr searches for the gcda files in the search paths: any (unnamed) parameters you pass to gcovr. For example, gcovr --root foo bar qux specifies two search paths bar and qux. By default, gcovr searches all subdirectories of the current working directory.
Related
I want to compile some C code with GCC but having problems with linking the necessary files.
I have a simple .c file that includes 3 header files from other repo projects that I have downloaded and put in my working folder. The -I command lets me add folders to the compilation but it fails on one of the repos because it seems like the command is not recursively looking through subfolders.
How do I tell the compiler that he has to look for includes in all subfolders of my current working directory ?
The program I want to profile with gcovr (or gcov/lcov) is located on a shared filesystem, along with the build directory from compiling the program, and I have multiple workers with which I intend to test my program, in parallel. To solve the race condition problem (the workers will all run my program, therefore all generating gcda files, named the same, in the same location on the shared filesystem), I redirect the gcda files to a separate target directory on each worker (as described here), and I have been running the following command:
gcovr -v -r /absolute/path/to/root --html --html-details -o test-details.html --object-directory=/absolute/path/to/object/dir /absolute/path/to/gcda/dir
where the last path is the search_paths, described here. I expected this to look in /absolute/path/to/root for the program source, /absolute/path/to/object/dir for the .o files, and /absolute/path/to/gcda/dir for the gcda files. However, I ran it with -v and I'm seeing that gcovr is running gcov commands in the form of this, from the root dir:
gcov /absolute/path/to/gcda/dir/file.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /absolute/path/to/gcda/dir
Again, I expected it to run in the form of this (look at the --object-directory path):
gcov /absolute/path/to/gcda/dir/file.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /absolute/path/to/object/dir
It behaves properly when run like the latter command, but gcovr is running the former. I'm only using gcovr instead of gcov because I have a large project (I know gcovr is built off of lcov). Does anyone know why it is behaving like this? (Is this the way it is supposed to run?) How can I make it so it behaves the way I want? Thanks in advance!
This was cross-posted to the gcovr issue tracker on GitHub, here's the summary:
Gcovr currently expects that the .gcda and .gcno files are right next to each other (which is usually the case). The search paths affect where gcovr searches for these files. The --object-directory only provides a default value for the search paths, but here you have overridden that with an explicit search path. The gcovr --object-directory option is not passed through to the gcov --object-directory option.
As of gcovr 4.1 there is no option to solve this. You will have to copy the .gcno files from the build directory into each directory with coverage data. Alternatively you can run gcov manually and then aggregate the .gcov files with gcovr -g ....
Additional notes:
gcov is not interested in the .o object files, only the .gcda files (written during test execution) and the .gcno files (written during compilation).
gcovr and lcov are not directly related
I'm trying to collect code coverage for the project that has c++ and c code both on Ubuntu.
I use '-fprofile-arcs' and '-ftest-coverage' values as CXXFLAGS and CFLAGS; '-lgcov' as LINKFLAGS.
Common C project structure is:
c_code\
src
unit_tests
src contains sources of static library.
unit_tests dir contain tests written with googletest framework e. g. tests of kind
TEST_F(test_case_name, test_name) {
some_gtest_assertions;
}
After the build googletest binary that should contain static library to test inside of it is launched.
Building and running of the project binaries results in generating of *.gcno and *.gcda files. However my C coverage results are empty (C++ is generated well).
lcov command has the folloiwng format:
lcov --capture --directory my_c_gcda_location --output-file c_coverage.info
Logs of lcov show the following for C-related gcda files:
gcov did not create any files for "my_c_gcda_location/*.gcda"`
There are also errors of kind:
*.gcda:stamp mismatch with notes file
Should I specify some additional parameters or perform some additional actions to get coverage results for C? Or what can be the reason of these issues?
You may get "stamp mismatch" when the .gcda files are newer than the .gcno files.
It can happen mostly for 2 reasons:
1. You might have re-build the code after running the test and before trace file generation.
2. The binary might be built in one machine and test was ran in other machine, whose time is ahead of the build machine.
For these two cases you have to just make sure the file creation time of .gcda is greater than .gcno and .c* files.
You can do that by just doing "touch *.gcda" and then run the lcov command.
My project's directory structure is basically as follows:
root/src
root/assets
root/library
I currently have CMake set up to compile the source, compile the library, and then link them, by calling make from the root directory.
I then have to manually move the executable into the original assets directory to get it to run, since that's where it expects to be (and we want to test with our directory structure in assets as close to what we expect it to be when it's done).
So, is there any way to tell CMake to automatically stick the compiled binary in that directory, as well as copy the assets over? Since we're doing out of source builds, sticking the executable back into the original project source's assets folder seems odd.
In short, two questions: Is there any way to get CMake to copy assets as well as code, and is there any way to have it copy the generated executable to a specific location in the build tree?
Any help would be appreciated --- thank you!
Here's a simple example with a structure like yours:
root/src/main.cpp (only source file)
root/assets (where I want the executable to go)
Here's the cmake file:
PROJECT(HelloCMake)
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${HelloCMake_SOURCE_DIR}/assets)
add_executable (HelloCMake src/main.cpp)
When I build against this using Visual Studio I get the output placed in root/assets/debug. I'd have to dig to figure out how to get rid of the extra configuration folder (debug). Not perfect, but hopefully that gets you on the right track.
Edit...Even better:
INSTALL(TARGETS HelloCMake DESTINATION ${HelloCMake_SOURCE_DIR}/assets)
I'm using QTCreator as a code editor for my C++ project, not using the real features of the qmake compilation process.
My project has several subdirectories, in all of which I ran qmake -project to create a duummy .pro file that simply lists the source and header files in the directory.
In my root folder, I simply created a "main.pro" file that includes all these "subdir/subdir.pro" files.
So it looks like this:
./
main.pro
subdir1/
/include
/src
subdir1.pro
subdir2/
/include
/src
subdir2.pro
Now my problem is, I use some files that have a special file extension (say, .ccp), which are actually some C code but are used in a different step of my compilation process.
They are naturally ignored by the qmake -project command and do not appear in my project.
I read here that I could use the qmake setting QMAKE_EXT_CPP to tell it to gather my files as a C-code file, but it doesn't seem to be working.
If I run qmake -query QMAKE_EXT_CPP, I get .cpp::.c::.ccp (which I set right before), but when running a new qmake, it doesn't take my .ccp files in account.
So, three questions:
Is it possible to make qmake take some special extensions as a C++ file, when building the .pro file?
If yes, is it correct to use the QMAKE_EXT_CPP setting?
If yes, what should be the syntax of the QMAKE_EXT_CPP setting? (mine inspired by this forum post, but it might be bogus).
You cannot change QMAKE_EXT_CPP with -project option. The list of cpp extensions used at this stage is hardcoded into qmake. However after initial creation of .pro file you can edit it to extend with support for other extensions:
in test.pro
QMAKE_EXT_CPP += .ccp
SOURCES += test.ccp
You have to add new files manually.