Multi-platform analysis for C++ solution

Hello!

We are using SonarQube for our C++ solution. It works absolutely fine. However, our software is multi-OS so we have some parts of the code which are guarded by macro specifically for certain OSes. For instance, Windows OS has its own small part of code which is not generated for other OSes during compilation. Right now we use SonarQube for Linux platform so the code related for Windows is not being analysed.

We can compile and scan the code for multiple OSes and generate SonarQube reports but is there a way to combine these reports together? Is SonarQube capable to determine that 2 reports come from the same commit but just different OSes or will the newest report override the previous one?

Hello @ihar.hubchyk,

This is not a scenario for which we have direct support.

If you have the enterprise edition, a feature may help you nevertheless: The mono repository support:

You can have two different projects decorating the same pull request. Projects will still be different on SonarQube side, but your pull request will contain the quality gates from both projects, which means that both will have to be green for someone to merge the pull request (depending on your settings, of course).

Hope this helps!

Hi @ihar.hubchyk

we also have this multiarchitecture software.
We are using the branch feature for this.We append the os/compiler/arch to the branch name before analyzing. This might not be the intended use, but it works. You still cannot see all issues combined. You can switch easily which is ok for us.

image

@JolyLoic
That said, we struggle with the Pull Request Decorator feature. We are still working on this, but I think multiplatform support needs to be added here. We can only se one run in the branch (the latest?) selector.

Hello @KUGA2,

Yes, using different branches of the same project to simulate different architecture clearly presents some advantages, but cannot work nicely with PR decoration.

The answer I suggested present another trade-off, that can work with PR decoration, but at the cost of having to manage separate projects.

I fully agree that a better solution will require changes in the product. :crossed_fingers:

Hello @KUGA2

We are considering a new feature to help with your use case.
Please, consider upvoting it at
https://portal.productboard.com/sonarsource/3-sonarqube/c/315-analyze-multiple-code-variants

I may add a few questions

  • are using one CI per OS?
  • If multiple configurations on one build were supported, would it help you? for instance with using cross-compilation?
  • are using one CI per OS?
    Well. We have 1 pipeline (Azure DevOps) with multiple parallel jobs for building on different OS/Arch.

  • If multiple configurations on one build were supported, would it help you? for instance with using cross-compilation?
    Sorry, I do not get this question.

We are considering a solution which would require (at least in a first step) to build and analyse all different configurations successively on a unique machine. We’d like to know if such a solution would be compatible with your constraints.

Thanks for clarifying.

No, this is not sufficient.

  1. We cannot build on the same machine (Linux/Windows, cross compilers are not feasable here :/)
  2. We have multiple runs that take at least 30 mins each. Doing this sequentially would mean huge build time.

Hello @KUGA2,

Thank you for that data. We’ll take it into account when revisiting this subject.

So building project for SQ with build-wrapper on different platforms produces different build-wrapper.json.
Isn’t it possible to just merge those jsons to enforce SQ analysis on whole project?

Hi @AntonioHa

If you do so, any C++ source file compiled on different platforms will only get analyzed once, for one of the platforms. This is not usually what is wanted for multi-platform analysis.

Merging 2 json files is not trivial, believe me… However, SQ could read multiple files ( build-wrapper.json or preferably compile_commands.json because its more like standard) and check mutliple #ifdef paths in the files. The issues must be clearly marked from which “toolchain” (or platform) they come from. Maybe like a tag that can be filtered.

This might be a solution for better multi-platform support.

Hi @KUGA2,

My previous answer did not mean that there is nothing SonarSource can do to improve the situation. It just meant that I don’t believe that what was proposed can work without changes in the product.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.