For running PC Lint Plus, we currently use the compile_commands.json.
This works, but had some caveats when it comes to excluding supplied SDKs and such from our analysis, as they would be included in the JSON as well.
Recently I found out you can actually configure this per target using EXPORT_COMPILE_COMMANDS.
That would improve things, but the downside is that some tooling (e.g. VS Code CMake Tools) turns this feature ON globally when calling CMake.
This would mean that we would have to exclude targets explicitly, but that becomes a pain to manage when we pull in other pieces of code (for our own code we could add a CMake option probably, but with third party code I’d will be another story).
Therefor I was wondering if I can somehow generate such a JSON file per target, next to the “global” one.
This would allow us to create specific targets for running PCLP on other specific “code” targets.
An additional advantage would be that it could allow us to only analyze part of the code in a project instead of all, if we are working on a specific component.
I was thinking that if there is a generator expression that could somehow give me all the parts of these commands, that would probably also work to create PC Lint Plus targets that only analyze specific targets.
I could potentially use that, but then I’d have to fully “copy” an existing target and probably add a post “build” command as well.
PC Lint Plus comes helper scripts to configure it either via this JSON file, or by running an “imposter” compiler, which basically logs all compiler invocations to a text file.
I didn’t go with the “imposter”, because that would require me to reconfigure the CMake project with a special option set to use that fake compiler and I already had the compile_commands.json from CMake.
Let’s say I have a target created with add_library or add_executable, is there an easy way to create a target that copies all the configuration for those targets (e.g. source files, compiler defines, etc.) to which I can then add an override for the <LANG>_COMPILER_LAUNCHER?
The thing I really want to avoid is having our developers need to reconfigure just to run the SCA tools.
Another option I was considering was simply calling ninja -t compdb <rule> from a CMake script to generate the compile_commands.json for a specific target.
The downside is that I’d have to replicate the name of the <rule> based on the CMake target name and configuration.
Final thing I came across thus far is <LANG>_CPPCHECK which I think keeps all (or at least most) of the needed compiler arguments in tact.
Only downside is that it seems to always be combined with compiling a target.
In our CI pipeline, we typically build (mostly cross-compile for ARM Cortex-M targets) first in one container and run the SCA in another container afterwards (without reusing the cache and such). It would be a waste to recompile just to be able to run the SCA tooling.
Is it expensive to reconfigure? What’s wrong with having two build trees, one with and one without?
Using something like ccache would help here; the actual compiles would be cached at least.
That said, there’s no mechanism currently available to have different compilation databases. This might be a reasonable request (though something has to “lose” and not get compile_commands.json as the filename).
Reconfiguring is not that bad, but it does take time and interrupts the flow.
Multiple build trees could work, but I’m not sure how we’d integrate that into Visual Studio Code.
Currently we can just start the PC Lint Plus task, regardless of the configuration and such being selected.
I think something like <target>.compile_commands.json would do. Preferably the name/path should be retrievable via a generator expression, as this can then be used to pass the path to the configuration script provided with PC Lint Plus. Where should I propose such a feature request?