Sonar-scanner with C/C++ family fails after upgrade to 9.3.0 from 9.2.2

[tallandtree (Mariska Hoogenboom)]

Description problem

After upgrade of SonarQube Developer Edition from 9.2.2 to 9.3.0, the C/C++ sonar-scanner run fails with the following issue:

INFO: Sensor CFamily [cpp]
INFO: CFamily plugin version: 6.30.0.42324
INFO: Using build-wrapper output: D:\G\8XYozyKs\0\XXX\build\sonar-data\build-wrapper-dump.json
INFO: Available processors: 8
INFO: Using 4 threads for analysis according to value of "sonar.cfamily.threads" property.
INFO: Loading cache from: D:\G\8XYozyKs\0\XXX\build\sonar\cache\analysis_state
INFO: Existing cache invalidated and deleted, change detected in plugin version
INFO: Trying to deduce "INCLUDE" environment variable from D:\G\8XYozyKs\0\XXX\windows\packages\Ccv.Vx.Microsoft.VS2017.Cl\bin\CL.exe
ERROR: Could not find Visual Studio install from: D:\G\8XYozyKs\0\XXX\windows\packages\Ccv.Vx.Microsoft.VS2017.Cl\bin\CL.exe
ERROR: The "INCLUDE" environment variable was not found, make sure that you are running the analysis from the right environment. Skip analysis of files: 

The only change seems to be the version of the build-wrapper plugin: now version: 6.30.0.42324 and yesterday version: 6.28.0.39490, when the analysis ran successfully.

We have tried with a newest version of the sonar-scanner 4.7 as well. Same result.

If you check the generated build-wrapper-dump.json, you see a lot of “showIncludes”, but no “INCLUDE” variable.

Hope someone knows a workaround. Else we will have to rollback the upgrade.
Thanks,
Mariska

[JolyLoic (Loïc Joly)]

Hello @tallandtree,

We recently improved the accuracy of our analyzer by detecting in more cases the value of the INCLUDE environment variable that defines some default include paths. Unfortunately, it seems that this improvement fails to work on your environment.

While using the build wrapper, we detected that you are using a compiler with the following path: D:\G\8XYozyKs\0\XXX\windows\packages\Ccv.Vx.Microsoft.VS2017.Cl\bin\CL.exe, so to infer the value of INCLUDE, we tried to probe this compiler, but we can’t find this executable.

One of the constraint of our tool is that it needs to have access to the same tools during analysis as it had during build:

> The Build Wrapper collects information about the build including absolute file paths (source files, standard headers, libraries, etc…). Later on, SonarScanner uses this information and needs to access those paths. Whereas this is straightforward while running these 2 steps on the same host, it is worth some consideration when using any sort of containerization.

It looks that you are not respecting this constraint, and while it may have been benign in the past, it is now blocking you because of this improvement.

Therefore, the best solution would be to investigate where your build environment differs from your analysis environment, and correct those differences.

After discussing with one of my colleagues, I discovered I missed some points in my previous answer, so please disregard it, and only consider what comes next:

We assume the when you build code with visual studio, you do it from a normal installation of visual studio. In such a case, the environment variable INCLUDE should be defined. When this is not the case, we try to infer its value from the path where the compiler is installed, but in your case, this path is not typical either, so we fail.

We would like to understand your use case better (it is possible that your previous analysis “worked”, but produced bad results…), and for that, we would need to see your build-wrapper-dump.json file. Can you send it to us? (if you want to send it privately, please let us know).

As a temporary workaround, you can add a empty INCLUDE variable to your environment, or add to your compiler command line the switch -X to explicitly say you don’t want to process the INCLUDE environment variable.

Hope this helps,

[tallandtree (Mariska Hoogenboom)]

Thank you for your fast reply.

In general, this project builds embedded code with several cross compilers that not all use INCLUDE variables, therefore we can’t use INCLUDE variable. Instead we use the “-I”.
On our buildserver, we have all different compilers wrapped in NuGet packages, so we have a repeatable build environment. The same version is used within the build and for the sonar analysis.

Setting INCLUDE to empty doesn’t work, but we found out that setting INCLUDE=“C:\” does work.
We are developing a small test hello world application, which I can share with you. I’ll add it later.

Regards,
Mariska.

[JolyLoic (Loïc Joly)]

Hello @tallandtree,

Indeed, setting INCLUDE to empty is like un-setting it, so it should be set to any non-empty value. And with the additional context you have provided, I think we now have enough information to understand your situation.

For now, we are going to keep the current behavior, because, in other situations, it could detect actual configuration issues, and it is easy to add a variable or a switch to make the analysis work if, like in your case, you don’t want include paths to be defined by INCLUDE.

I’d also like to suggest that using the -X switch instead of the variable might have other advantages. It will work for the analysis, but it will also make your build more robust: even if your environment has by mistake defined an INCLUDE variable, this variable will be ignored.