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