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

Stephan Bergmann sbergman at redhat.com
Mon Oct 1 07:01:56 UTC 2018


On 30/09/2018 15:16, Maarten Hoes wrote:
> sberg wrote
>> 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.
> 
> Actually, these are all good points. I hadn't even considered these yet, I
> went straight into 'oh-goody-shell-scripting-time!' mode. Sorry for that ;-)
> 
> Having said that, I personally do think it might reduce the noise of the
> cppcheck report if cppcheck could at least be told :

I personally think a static analysis tooling with even only a single 
false positive caused by inexact invocation of the tooling (i.e., not 
passing the same command line switches as are passed to the real 
compiler) would be just a waste of time (and I personally wouldn't even 
bother looking at the results then).  Your mileage may vary---widely 
even---of course.  And I surely don't want to kill any enthusiasm and 
effort with this, just put it into perspective.

And from the other parts of this thread I see a move to that already 
existing gbuild-to-ide thing, which sounds very promising.


More information about the LibreOffice mailing list