C++ and cmake: Running sonar scanner on compile_commands.json

Hi,

We’re using both sonar scanner and cppcheck on C++ code. Sonar scanner requires the build-wrapper to wrap the build and listen to compiler commands which cppcheck can run based on compile_commands.json which CMake can generate without having to do a full build. This means that we can run cppcheck in parallel with the build while sonar scanner must wait for the build to complete.

We’re now wondering if it would be possible to have sonar scanner support reading compile_commands.json instead of needing to wait for the build to complete? This would bring it up to part with cppcheck in this respect.

Details on the compile_commands.json can be found here:
https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html

All help much appreciated.

Hi @tern-nils,

Running sonar scanner on compilation database is something we are considering.
We have a ticket for that:
https://jira.sonarsource.com/browse/CPP-1428
As of today, I cannot give you any timeline for this but at least, you can follow the progress.

In the meantime, the only thing I can suggest to minimize the overhead might be to use ccache to significantly speed up your build.

I hope this helps.

Hi @Geoffray,

Thanks for the response. We would be very happy to see this happen. It would allow parallelizing our jenkins pipelines and reducing build times quite a bit. We already use the cache fortunately - but not being able to parallelize is a real weakness in sonarqube compared to other tools we’ve used.

Cheers,
Nils

Hi,

Am I right to deduce from ticket https://jira.sonarsource.com/browse/CPP-1428 that the “build-wrapper” will not need to rebuild the C++ code anymore if we use the proposed “workaround” :
a python file which translates the compilation database (i.e. the file compile_commands.json) into the required compilation properties (compiler flags/arguments/includes locations) ?

It would be such a time-saver for our teams :
Our teams of C++ developers (using VSCode and CMake) would be alerted about their bugs shortly after the commit, instead of the next morning !

It would greatly increase the added value of SonarQube, in the eyes of both the developpers and the managers.

1 Like

Hi @cyril.og!

You are indeed right. If you can accurately generate the compilation database, convert it and feed it to the analysis, you do not need to build the project inside the build-wrapper.
But, please do note that this is a workaround provided to help non working cases. It is not thoroughly tested and it is not officially supported.
If an official support comes up, the ticket will be updated accordingly.

Cheers,

Geoffray

1 Like

Thanks @Geoffray, this is great news for us : having to recompile our whole project using the wrapper is really decreasing a lot the benefits of Sonar C++ scanner.

Our project is huge, thus it takes a very long time to compile.
So we’re doing incremental builds during the day, and full rebuilds are only done nightly.
=> C/C++ developers have to wait for the next morning to know if Sonar scanner detected issues in their code. If yes, they must redo the testing phase :frowning: + wait for another day for the next scanning :frowning:

To be honest, we are currently investigating other C++ static analyzers than Sonar, so as to provide feed-back to our C++ developers in real-time instead of each morning.

But now there is hope we can solve that issue using your “not-officially-supported-workaround” : it would be a great improvement for us, not just a “workaround” :wink:

Cheers,
Cyril.

Hi @cyril.og

Thanks for providing these additional details. We really value this information.
2 points:

  • as I previously mentioned in the thread, did you consider using ccache? It allows to perform a full build with a speed close to an incremental build. It works well with our analysis. Additionally, even if not using ccache, our analysis cache (described there) would be really valuable in your case.
  • for an official support of compilation database, stay tuned and watch the ticket. I cannot make any firm promise yet but things are moving.
1 Like