The Build of a project depends on different targets and the codebase has different defines

We are using Sonarqube Version 8.9.3.
We are looking into integrating sonarqube into our pipeline for the repos we work on.

The issue is that we have a codebase which we build a number of times with different #defines(multiple #ifdefs within C files). So we build our projects number of times for different target.

What is the best approach to analyse this - to find issues in each combination.

  • Analyse each project with different json generated with respect to the target as a separate-separate SonarQube project but It’ll be a very long process and the requirement is that scanner should scan a good percentage of code-coverage.

Is it possible to analyse all builds within a single Sonarqube project

  • can you combine build-wrapper output from multiple runs?

I thought of merging all the json output with respect to one target but then I have my doubt with scanner that whether it is going to overwrite the report considering such long bw-output .json file.
Also is there any coverage tool that could provide the coverage report for sonarqube using static approach but not dynamic.

Can you please suggest an easy and smooth approach to deal with this issue.

Hi,

Welcome to the community!

Unfortunately, we don’t have a smoothly packaged procedure for you. I think your best bet is to do the analysis of each #define variation.

Because you’re analyzing C / C++, that means you’re in Developer Edition($), so license-wise you probably want to analyze each variation as a branch of the main project.

 
HTH,
Ann

Hi @prbhatt,

In addition to what @ganncamp told you, I can answer this question:

  • can you combine build-wrapper output from multiple runs?

You can, technically, but then if a source file is mentioned several times, only the first occurrence will be analyzed, and the others will be ignored. So this will not do what you want to achieve.

We have a currently opened feature that targets improving this situation, you can vote for it and describe the details of your use case in our portal.

Thankyou @ganncamp and @JolyLoic for the inputs.
could you comment on coverage tool part too?

Hi @prbhatt,

The coverage component of the question was not clear to me, and we try to keep it to one question per thread (things get messy, fast otherwise). So could you create a new thread for the coverage question, with all the details needed to understand it?

 
Ann

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