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

[Maarten Hoes]

Hi,


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 :

1.) In what directories the include files are located (Yes, if you have both
foo/foo.h and bar/foo.h this will cause issues, but might still be
preferable to what we have now).
2.) What are some likely defines, like for example: -DLINUX (Duh),
-D__LITTLE_ENDIAN__/-D__x86_64__ (characteristics of the test system
cppcheck is currently run on) -D__GNUC__ (expected, and not likely to cause
issues if set for code that does not have GNU C extensions), and
-UMACOSX/-UFREEBSD/-U_WIN32 (script currently does not run on MAC, FreeBSD,
or Windows).

Just my 2$.


- Maarten.



--
Sent from: http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html