USABILITY: initial config experience is... weird. (missing hints!)

[Andreas Mohr]

Hello all,

when initially doing a cppcheck invocation on a more complex project,
cppcheck keeps spewing unknownMacro errors.

Checking Foo\Bar.cpp ...
Foo\Bar.h:108:2: error: There is an unknown macro here somewhere. Configuration is required. If DECLARE_MESSAGE_MAP is a macro then please configure it. [unknownMacro]

This error message is sufficiently confusing/misleading/imprecise since
in most cases this is a case of letting cppcheck know where to
resolve include paths to the required headers which happen to already be
defining these macros.
I.e. it is NOT a macro configuration which is required (-D), but rather
[simply?]achieving proper lookup of existing macros.

Text suggestion: "then please configure it or configure include path to its
existing definition site."

Worse, one cannot even figure out that
include path setup is the actual problem of missing macros, since
detecting/visualizing #include resolution progress issues requires
properly full logging, which can only be achieved via
-enable=all (i.e., --enable=missingInclude specifically).

Yet, cppcheck --help does not even mention a "log"/"logging" keyword in its entire help text!!!!
(it likely should be mentioning it somewhere within the --enable cmdline
option help text).
So, we have a cppcheck which is defaulting to simple no-log operation (which
is wholly appropriate I guess), but then does not directly hint at
which options do provide such crucial logging.

Anyway, after so many complaints (about issues which need to be improved):
thanks a ton for a very useful tool!!

Greetings

Andreas Mohr

[Andreas Mohr]

Also, cppcheck possibly doesn't provide a Show Includes (MSVS)-type (or: gcc -H) log functionality - which however likely is a crucial functionality when trying to re-create a functionally completely equivalent parsing tree within a sufficiently complex source environment.
So you may have a case of some important infrastructure define (think _M_X64 or _MSC_VER stuff) not yet being -D:d, and this resulting in some infrastructure #include not getting done, thus getting a completely mismatching traversal of #include hierarchy (mismatch of cppcheck processing vs. MSVC processing, that is).
Thus you end up with a "compilation" mismatch without being able to properly debug it (since you cannot figure out where some conditional causes skipping of some required #include parts).

Also, the "logging" keyword should also be added to the "--bug-hunting" cmdline option.