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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux