SonarCFamily - Compile same code base with several compilers

SonarQube
1
  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)

Latest SonarQube 8.1-beta docker version for Developer edition

  • what are you trying to achieve

We are shipping our libraries on several targets, either Linux/Windows/embedded, and for several compilers/toolchains (IAR, Visual Studio 201X, Keil, GNU-ARM, Android, …)

Our continuous integration process will build for each of project delivery targets, using relevant compilers/toolchains.

How would you recommend us to proceed to ensure that, while running sonar-scanner analysis for each target, uploaded results are not overriding each others?

2

Hi @scm_invn,

currently, multi-configuration analysis are not supported by default. The (probably only) way for the time being is to analyze each configuration into a different project, it is also the most verbose but the only solution which would allow you to catch all issues coming from all configuration. The other option is to reduce as much as possible platform dependent code which has the most benefit.

3

Thanks for the feedback @mpaladin.

You are right in the sense that we have very little adherence with targets, and usually the proper toolchain/compiler will take care of specifics includes/defines.

As we will use the Developer edition, we cannot afford to duplicate projects as it would eat up our LOCs.
Could “branch” analysis help us, as we could craft some <branch_name>-<target> sonar.branch.name properties?

Disclaimer: we are just moving to sonarqube, so still have a lot to read/learn

4

Hi @scm_invn,

Indeed.

Unfortunately it wouldn’t help.

:+1:

5

Could “branch” analysis help us, as we could craft some <branch_name>- sonar.branch.name properties?

Unfortunately it wouldn’t help.

I think formatting strip down some information, idea was to create the sonar.branch.name analysis parameter with a combination of <scm_branch_name> and <build_target>, like for example master_gcc5

6

Hi @scm_invn,

if you intend to use branches for multiple configuration it wouldn’t really solve the problem you are trying to solve.

7

Sure, i would need to test it to see how it works and if results are usable.
But at least it would not eat-up our LOC right?

8

Hi @scm_invn,

yes, it should not eat-up the LOC.