`use "genhtml --ignore-errors source,source ..." to suppress this warning`

[dilyanpalauzov]

I have genhtml: LCOV version 2.0-1 . I compile with clang-cl.exe (Clang wrapper to understand the Microsoft’s C++ compiler command line parameters) some files under Windows. Because of some mismatch between the file names in git (thus Linux) and in the build script under Windows, the debug/profiling information does contain the file name in wrong case and under Linux genhtml cannot find it:

genhtml -o abc uu.info
Found 317 entries.
Found common filename prefix "/git/A1"
Generating output.
Processing file B2
  lines=192 hit=0 functions=27 hit=0
Processing file src/win32/include/c3.h
  lines=63 hit=0
Processing file src/win32/redev/d4.cpp
  lines=40 hit=3 functions=7 hit=1
Processing file src/win32/redev/e5.h
  lines=1 hit=0 functions=1 hit=0
genhtml: ERROR: /git/f6.h is not readable or doesn't exist. See the '--substitute' and '--synthesize-missing' genhtml options for methods to fix the missing path or ignore the problem.

Now I run

genhtml --synthesize-missing --ignore-errors source -o fifi uu.info

and genhtml prints

genhtml: WARNING: ('source') cannot read '/git/g7.h' - synthesizing fake content
        (use "genhtml --ignore-errors source,source ..." to suppress this warning)

The problem report is that on invoking genhtml --ignore-errors source genhtml suggests to call "genhtml --ignore-errors source,source ..." to suppress this warning. So the suggestion is to use twice source after --ignore-errors. For me this makes no sense.

[henry2cox]

Man page is your friend.

  --ignore-errors errors
          Specify a list of errors after which to continue processing.

          Use  this  option  to  specify  a list of error classes after
          which genhtml should continue processing with a warning  mes?
          sage  instead  of aborting.  To suppress the warning message,
          specify the error class twice.

          errors can be a comma-separated list of  the  following  key?
          words:

The idiom is 'once to turn error to warning, twice to silence entirely'.

[henry2cox]

Should also add that the --substitute option exists for precisely this purpose (wrong paths encoded into object data, or build structure which doesn't match source/revision control structure). Substitutions are pretty much identical to what you would get by running sed -e ... on your input data.

[dilyanpalauzov]

I do not see how the --substitute option would help. Some letters in filenames must be uppercased, others lowercased. There is no rule, except looking on the file name actually on the system. But this is essentially the same as looking the files on the filesystem and replacing the filenames in the lcov file.

If there was option to ignore uppercase/lowercsee from filenames, then it will do what it is supposed to do.

Concerning double source, source I agree I have not read the documentation in detail before reporting here and this is my fault.

Adding case_insensitive=1 also does not help. I lowercases all paths (on Linux), while on Linux some letters must be uppercase. The use case is: I generate by clang the lcov data under Windows. Then move this lcov file under Linux. Then change on SF: lines \ with /, change with C:… prefix with something suitable. At this moment filenames as in the lcov data and on file system match in case-insensitive manner. In particular the suitable prefix from above is lowercased and in this form it does not exist.

[henry2cox]

There are a lot of issues with such a solution, but you can have as many --substitute patterns as you want...they all get applied, in the order specified.
So: is some strings need to be upper-cased: add a regexp for that. Is some need to be lower-cased: another regexp for that - and so forth. This rapidly gets out of hand - so other options exist.

A better solution for you is probably to use a --resolve-script - which breaks up the paths and does partial matching. Such a script is not particularly hard to create (ours wasn't upstreamed - at least partly because it is pretty specific to our source code and revision control system).

The use case for the case_insensitive option is to go the other way (linux to windows) - as we know that the linux filesystem is case-sensitive and the windows one is not. For other scenarios: we use a resolve script.

[dilyanpalauzov]

Fair enough. Closing.

[henry2cox]

I forgot to mention: if your application is genhtml, then you can probably get the effect you want with --annotate-script instead. The tool doesn't actually need source code in a build directory to generate a report - remote repo is fine.

This gets harder if you also want to use a --version-script - as it would also need to be trained. Similarly, if you want to save off coverage data - say, for differential reporting of your release - then you probably want to fix the paths before archiving. Almost always better to use complete, correct, and consistent data when you can.

The upshot: --resolve-script is probably the easiest and most consistent way to go.