Best way to handle oddball header #includes for Cppcheck Report?
sbergman at redhat.com
Thu Sep 13 08:58:02 UTC 2018
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 \
More information about the LibreOffice