-
Notifications
You must be signed in to change notification settings - Fork 265
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
gcovr confused by duplicate filenames #60
Comments
Digging a little deeper, this appears to be a bigger issue for autotools based packages as apposed to the hand coded single test Makefile in gcovr/tests/nested. If you use a single Makefile to compile, the subdir paths get embedded into objects and gcov reports. If you have a package that uses automake then you tend to have a Makefile per subdirectory and the path names no longer get embedded and generating all gcov reports in starting_dir will greatly confuse gcovr. To help see issue, I modified nested test to have a Makefile in subdir/A and subdir/Makefile to link in those precompiled objects. Here is result of gcovr from that modifications. Notice how most items under subdir/A are missing from report:
|
Given the difference that you note, is this a gcovr issue or a gcov issue? Can you provide a test example that we can use to motivate a fix? On Sun, Aug 3, 2014 at 5:27 PM, Chris Bagwell notifications@github.com
|
I think its likely a gcovr issue with assuming the root of all compiles is starting_dir. I'm new to gcovr but it may have worked fine before 3.2 when it starting chdir()'ing before running gcov. Let me find some time to package up a modified version of 'nested' example distributed with gcovr and we can go from there. |
However there are some issues in tests in shared_lib. I don't know gcovr sufficiently well to understand if that's a real problem or no.
Hi, I created an example in 23b7d41 (highly inspired from the nested test). The current version of gcovr would produce that output (when launched with
Or that output when launched with
The second case is better but still all the subdirectories are ignored (except for main.cpp). With my commit 6fa250f the output is now (when launching
which totally reflects the directory hierarchy. However the tests in shared_lib now fails. I need help to understand if that's an issue or not. There is a difference in the coverage.txt, but my version seems better to me. There is also a difference in the coverage.xml file (in the package tag) but I'm unable to tell if the difference matters. I think correcting this issue #60 is very important since it makes gcovr unusable with Cobertura plugins as soon as you have several Makefiles (which is not unusual with large projects). |
Thanks for creating a test case with issue, @mikael-s . I hadn't found time to push one myself. Also, I see you have prototype fix for issue on your fix_nexted_makefiles branch. I had a similar work around that I've been using. For my case, I commented out the call to os.chdir() in process_gcov_data() and this 1 line change works for my nested Makefile cases. I'm guessing it causes other problems but lets me keep using Cobertura plugins. |
@cbagwell, just curious, which of the os.chdir() calls in process_gov_data did you comment out? I'd like to try it on my setup. Thx! |
I commented out only the first os.chdir() call in process_gcov_data(). The one that says os.chdir(starting_dir). As kinda mentioned in comment #2, this os.chdir(starting_dir) means gcovr supports 1 Makefile that references files in nested subdirectories but doesn't handle well nested subdirectories with a Makefile per directory. In former case, subdirectory info is stored in gcov data and so temp files are created of form $starting_dir/path#to#filename but in later case temp files are created of form $starting_dir/filename and thus risk overwriting each other. Another bad thing that happens in later case is that since subdirectory names are missing, you also don't see them in gcovr reports and everything looks like its in root directory. Commenting out os.chdir(starting_dir) fixes that issue as well. |
Wow! Removing the os.chdir(starting_dir) solved several issues I was having. I still have the problem of a few duplicate header files, but the large majority were resolved. Also resolved was the issue where I specify a root directory and all the files show up in in a flat list. They now show up in relative directories. Seems like a nice change. I don't see a downside to it. Yet. :) Thanks! |
FYI, I found out what removing that line breaks. "--html-details" no longer works for me after removing the os.chdir(starting_dir). |
These changes didn't work for all problems, so I'm reverting them for now.
This issue has not seen any progress in a while, so I am closing it for now. If the problem persists, please add further details so it can be re-opened. If someone else is experiencing a similar issue, please create a new issue. In particular, the test case added by @mikael-s in 23b7d41 seems to pass. If that test case does not describe the intended behaviour or if the test case did not reproduce the actual problem, please explain in more detail. |
However there are some issues in tests in shared_lib. I don't know gcovr sufficiently well to understand if that's a real problem or no.
These changes didn't work for all problems, so I'm reverting them for now.
I saw this issue in a test project where some coverage data was not showing up in the gcovr generated reports.
I believe as of gcovr 3.2, all gcov reports are ran from starting_dir and output is stored in this single directory but nothing in filename contains subdirectory info.
Here is a made up project layout that has plugins for various audio formats:
root/src/main.cpp
root/src/read.cpp
root/src/mp3/read.cpp
root/src/wav/read.cpp
read.cpp.gcov would be generated in root directory 3 times and overwrite each other.
In my tests, only root/src/read.cpp shows up in reports because it happens to be last gcov ran.
The text was updated successfully, but these errors were encountered: