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

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.