Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Exclude flag broken on Windows #191
Since #152 was merged it seems like gcov is now generating detailed HTML reports on Windows. So the following works as expected - yay!
> gcovr -p -b --html --html-details -r . -o "build/artifacts/gcov/GcovCoverageResults.html"
However it appears that the exclude flag is now broken:
>gcovr -p -b -e "^vendor.*|^build.*|^test.*|^lib.*" --html --html-details -r . -o "build/artifacts/gcov/GcovCoverageResults.html" Traceback (most recent call last): File "C:\Users\Me\AppData\Local\Programs\Python\Python36\Scripts\gcovr.py", line 2326, in <module> options.exclude[i] = re.compile(os.path.realpath(options.exclude[i])) File "C:\Users\Me\AppData\Local\Programs\Python\Python36\lib\re.py", line 233, in compile return _compile(pattern, flags) File "C:\Users\Me\AppData\Local\Programs\Python\Python36\lib\re.py", line 301, in _compile p = sre_compile.compile(pattern, flags) File "C:\Users\Me\AppData\Local\Programs\Python\Python36\lib\sre_compile.py", line 562, in compile p = sre_parse.parse(p, flags) File "C:\Users\Me\AppData\Local\Programs\Python\Python36\lib\sre_parse.py", line 855, in parse p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, 0) File "C:\Users\Me\AppData\Local\Programs\Python\Python36\lib\sre_parse.py", line 416, in _parse_sub not nested and not items)) File "C:\Users\Me\AppData\Local\Programs\Python\Python36\lib\sre_parse.py", line 502, in _parse code = _escape(source, this, state) File "C:\Users\Me\AppData\Local\Programs\Python\Python36\lib\sre_parse.py", line 368, in _escape raise source.error("incomplete escape %s" % escape, len(escape)) sre_constants.error: incomplete escape \U at position 2
This will be fixed once #158 is merged. But even then, the filter is slightly incorrect because the current working directory is prepended. I.e. you would actually end up with this regex:
In the mid term, I think ALL filters need to be redesigned and/or clarified (see also #151). Some operate on relative paths, some on absolute paths, some regexes like this one are prepended with a path, ….
So at the very least this is a documentation bug, independent from #158.
@wolf99 It seems that you call gcovr directly from command line on Windows. How did you do that?
@goriy I added the
@wolf99 I had tried that way too. Yes, it worked, but I decided that it's a bit better to create additional file only once without manual renaming every upgrade. I hoped you could find some way to run gcovr without renaming...
I've seen some python packages which install .exe wrapper into
Thanks to #158 filters are now constructed in an unified manner. Unfortunately, #158 introduced a slight regression because it assumes filters are relative paths. The filter-test2 and #137 show the intent that filters can be absolute paths:
GCOVR_TEST_OPTIONS = -f `pwd`'/main.cpp'
If that test were adapted to use native Windows paths, we'd get
This raises a choice:
In both cases will a Windows path have to be adapted. Currently, absolute paths don't work under Windows, but relative paths with escaped backslashes do. Cygwin-style paths
I think requiring forward slashes is the better solution. This will break a few scripts. But it provides a clear mental model that's easy to communicate: “filters must use forward slashes, even on Windows”.
Pseudocode for filter matching then becomes:
def normalize_path(path): return os.path.realpath(path).replace(os.path.sep, '/') def match(filter, path): path = normalize_path(path) if not os.path.isabs(filter): filter = re.escape(normalize_path(os.getcwd())) + '/' + filter return re.match(filter, path)
This code should work on both Windows and Unixish systems. The current solution of feeding regex patterns into
What are your thoughts on this? @denniswjackson I'd also be interested in your perspective.
Generally I don't like the first case (where it's allowed to use backslashes as path separators in filters) because there's no way to distinguish between path separator and regex escape.
Second case seems much more attractive to me. I think that it's not a big problem to use only forward slashes as path separators in filters. Although they seem less "native" on Windows, but escaped double-backslashes seem even worse! It's impossible to use native windows paths "as is" anyway.
And I consider it a great advantage to be able to use the same scripts on different platforms.
As a result I agree that requiring forward slashes is the better solution.
I agree that the second option is more immediately attractive, even just from a visual standpoint.
To play devil's advocate though, if I was a Windows-native developer, I might simply copy and paste the path from Windows Explorer or the Command Prompt - which would include back slashes and be wrong for both options thus leaving the hypothetical me confused.
Not to say that Gcovr should support such a scenario, but are there other cross platform Python scripts that also deal with regex input that we could look at to see how they expect such input and how it is managed there?
Hi, sorry if my question is dumb, but how are we suppose to use this exclude filter now on windows? can someone give an example?
I am new to gcovr, and I dont know much about regex. I have a gtest setup and want to exclude all my gtest framework code, I tried the following, but none were working:
Thanks in advance
@dennykhoerniawan That's actually a very good question! Unfortunately, filtering is a bit of a mess.
For a moment I thought the new
But this will not:
Please report your results, because I'm not 100% sure about this myself. If this didn't work, please create a new issue where you explain
Thank you for your help. Without these reports, I wouldn't know about all the stuff that needs fixing :)