Does Cppcheck take more time when more included paths are there

[Krishna]

Hi @danielmarjamaki,

Tried above suggested method with only one file. It is hardly saving a 1 sec.

Found there is a multi-line macro defined with about 750 lines which is one of included path for all the .C files in the compile_commands.json. Deleting that macro from header file is reducing the execution time.

Find the attachment for a sample macro definition.

Now we would like to ignore cppcheck to exclude that macro. Something like below is helpful.
a. DISABLE_CPPCHECK
Piece of code here
ENABLE_CPPCHECK
(OR)
b.// Disable cppcheck for MACRO
#define MACRO

========================================================================
While experimenting found single line comment(Keeping like // #define) is not accepting by cppcheck on multi-line macro. That's why I had to delete macro from header file and run or use multi-line comment or need to keep single line comment for each line. This can be reproduced adding more macros in attached main.h and capture execution timing.

[Daniel Marjamäki]

Now we would like to ignore cppcheck to exclude that macro.

Yes one method I've used myself would be:

#ifndef __cppcheck__
... code hidden from cppcheck ..
#endif

When executing Cppcheck you can provide an extra -D__cppcheck__.

cppcheck --project=compile_commands.json -D__cppcheck__

[Krishna]

Hi @danielmarjamaki,

Hiding a code based on a macro is not saving execution time for us(May be due to big multiline macro). And I see we can't exclude .h files using the option -i in cppcheck. The multiline macro is defined in a header file and that path is added as a include path(-I) in compile_commands.json

Any alternative soution is helpful.

[Joel Wirz]

Hello there

We are using cppCheck build since two months and don't feel any improvements in build time at all. The files in the build directory get updated with each build and the folder contains over 4'021 files. A few details to our repository:

• We also run cppCheck over our testfiles. These testfiles are grouped into multiple libraries. Each library contains a set of files which have the same name accross all libraries (like TestSuiteSetup.c for example). Can the incremental check mechanism keep track of multiple files with the same name?
• We use git to version our files. If we take back a pull request, some files get updated (and receive a new timestamp). The cpp check itself is then executed on a build agent and previously all the files are checked out. In my understanding, only the files affected by the PR should be checheked which should result in significantly lower build times. Why is this not the case?

It would be beneficial if you could help us with this issue. I'm happy to provde more info if needed about our setting.

[CHR]

Which platform are you on? Do you use multiple jobs (-j=N)? Are all the files in the build directory recreated in every run?

[Joel Wirz]

We run cppCheck on Windows Server 2016 Standard.
We have two jobs where we execute cppCheck. One long running job which has all checks enabled and runs on 1 core (--enable=all, -j is not defined) and a short running job where some checks are disabled and all cores are used (-j12 --enable=style,information,missingInclude).

As far as I've seen only some of the files are recreated in the build directory.

[CHR]

The speedup is achieved by not analysing unchanged files (and thus not recreating the result files in the build directory). Can you check that only the expected files are changed?