Best way to handle oddball header #includes for Cppcheck Report?

[Stephan Bergmann]

On 12/09/2018 18:50, Luke Benes wrote:
> I am in the process of  teaching cppcheck about our source tree. So far I have reduced the number of warnings from ~9000 to ~100. In order for our weekly Cppcheck Report to benefit from these, I need to automate the process. Here is the command I used to list all of our include directories:
> 
> $ find . -type d \( -name "inc" -o -name "include" \) |sort > inc.txt

I'm not sure how useful this is, overall.  Apparently, Cppcheck is run 
on .cxx files without knowledge of the specific -I, -D, etc. compiler 
switches that our build system would pass to the compiler for a given 
.cxx file.  That will always lead to issues (Cppcheck not finding an 
including, or even finding the wrong include if there is include files 
with identical names in different dirs?, or producing false positives 
because it mis-guesses about some -D macro setting) unless we restrict 
our build system to compile all files with the exact same set of 
compiler switches---something I don't see us moving towards.

> This cuts the warning from 9000 to 300, but there are some oddball #includes that this misses. Here is an example from 'vcl/qt5/Qt5Bitmap.cxx':
> 
> #include <Qt5Bitmap.hxx><--- Include file:  not found.

...which e.g. is because of

> $(eval $(call gb_Library_set_include,vclplug_qt5,\
>     $$(INCLUDE) \
>     -I$(SRCDIR)/vcl/inc \
>     -I$(SRCDIR)/vcl/inc/qt5 \
> ))

in vcl/Library_vclplug_qt5.mk.