Is there an advantage to --addon?

[Richard Smith]

I see that cppcheck can now run addons directly with --addon. Is there an advantage to doing it over the previous way with generating .dump files and calling the addon directly?

Our CMake based buid system runs it as a separate dedicated step.

[Daniel Marjamäki]

The advantage is that you can run it directly from cppcheck.. it makes it easier to run the addon. You can save time as there is no need to run --dump in a separate step.

[Richard Smith]

Based on what I see in section 9.1 of the manual --addon and running directly are not equal. The manual says that if you need command line arguments that it still has to be run directly.

[Richard Smith]

Ah... I missunderstood the --addon=mira.json feature. I see that I can specify arguments via .json file. What directory is misra.json looked for by default?

[Georgiy Komarov]

Ah... I missunderstood the --addon=mira.json feature. I see that I can specify arguments via .json file. What directory is misra.json looked for by default?

No, the correct variant is --addon=misra.py. It will start the system's python interpreter. Addon script must be available in PATH environment variable.

I see some drawbacks here.

First, we can't pass command line arguments when calling addons from cppcheck. Currently, you should call addon script directly, I wrote about it in README. Some addons such as misra.py require additional information like --rule-texts, so we need a way to pass this through cppcheck. May be an extra arguments in cppcheck cli interface (and additional form in gui), or something like configuration file.

Secondly, addon scripts are installed in BIN directory. This is somewhat unusual for *nix systems. It would be more logical to use something like /usr/share/cppcheck/addons for additional scripts. This approach used by most programs with addons features. For example, see file structure for inkscape deb package.

I also found that addons are not included in linux distribution packages at all:
+ https://packages.debian.org/bullseye/amd64/cppcheck/filelist
+ https://apps.fedoraproject.org/packages/cppcheck/

I suppose we can ask to include addons in distribution packages and fix default addons search paths in cppcheck.

[Richard Smith]

Ah... I missunderstood the --addon=mira.json feature. I see that I can specify arguments via .json file. What directory is misra.json looked for by default?

No, the correct variant is --addon=misra.py. It will start the system's python interpreter. Addon script must be available in PATH environment variable.

Works for me. --addon=misra.json works as documented.

Secondly, addon scripts are installed in BIN directory. This is somewhat unusual for *nix systems. It would be more logical to use something like /usr/share/cppcheck/addons for additional scripts. This approach used by most programs with addons features. For example, see file structure for inkscape deb package.

Nod. This probally should be changed. I agree that /usr/share/cppcheck is a better location. cppcheck should execute the python interpreter with it's python path set to where it can find the python addons.

I have to explicitly set the python path in my command line when the misra check is executed to check the .dump files.

[Daniel Marjamäki]

I don't think we can just install in /usr/shared/cppcheck/addons but need to allow packages to install in a custom location.

We have the CFGDIR now. Either we could add a new ADDONDIR so these can be set independently or maybe add a DATADIR or something that points out where we will store the platform files + cfg files + addons + ....

[Dzid]

Any idea why --addon=misra.py can't be found with cppcheck installed with MSYS?
https://github.com/msys2/MINGW-packages/issues/1309#issuecomment-1328128387