Xilinx SDK/Sonar Scanner for Jenkins “build-wrapper-dump.json” file was found but 0 C/C++/Objective-C files were analyzed

SonarQube
,
1

Still in the evaluation stage, I am setting up a SonarQube flow for the first time. This is for our embedded software C projects which are targeted at the Xilinx MicroBlaze platform. I am setting up a project in Jenkins (but first running locally on the Jenkins machine to debug the flow).

I am using the following -
SonarQube version 8.1.0.31237
SonarQube Scanner (Jenkins) version 4.2.0.1873
SonarCFamily Plugin version 6.7.0.15300
Xilinx SDK 2017.4 (https://www.xilinx.com/products/design-tools/embedded-software/sdk.html)

I have set up Jenkins build steps to pull the Mercurial repository and run the build wrapper as follows

C:\j\build-wrapper-win-x86-64.exe --out-dir build_wrapper_output_dir C:\Xilinx\SDK\2017.4\bin\xsdk.bat -batch -source “C:\j\xsdk-test.tcl”

Where my tcl file uses the commands “importprojects”, “projects -clean”, and “projects -build”. All of the above works correctly and and an output directory with the build wrapper log and json file is generated. I have attached these as text files. build-wrapper_log.txt (834.3 KB) build-wrapper-dumpjson.txt (350.1 KB)

I believe a user has previously used XSDK with SonarQube for analysis - see Sonarqube Problems after Upgrade 8.0. However I don’t know if I am running into the same problem, as the JSON file generated in this step seems to be several hundreds of KB. Could you check if the output is as expected? I don’t know what to look for.

I ran the following command locally on our Jenkins server, which calls Sonar Scanner for Jenkins: C:\j_Embed_SW\tools\hudson.plugins.sonar.SonarRunnerInstallation\SonarScanner\bin\sonar-scanner.bat -Dsonar.host.url=url -Dsonar.projectKey=projectkey -Dsonar.cfamily.build-wrapper-output=build_wrapper_output_dir -Dsonar.host.url=http://10.62.240.200:9000 -Dsonar.sources=path-to-source

This runs OK and I can see in the output that 38 C files have been indexed, which is correct.

However, I get

ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: The “build-wrapper-dump.json” file was found but 0 C/C++/Objective-C files were analyzed. Please make sure that:

  • you are using the latest version of the build-wrapper and the SonarCFamily analyzer
  • you are correctly invoking the scanner with correct configuration
  • your compiler is supported
  • you are wrapping your build correctly
  • you are wrapping a full/clean build
  • you are providing the path to the correct build-wrapper output directory
  • you are building and analyzing the same source checkout, absolute paths must
    be identical in build and analysis steps

It would be great to get another pair of eyes on this, to check if I’m running into the same problem as the post linked above, or if this is a separate issue.

2

Hi @meenalkb,

could you also share the output of sonar-scanner with the property sonar.verbose=true?

3

Hi @mpaladin,

Here it is -
sonarlog.txt (35.3 KB)

Thanks!

4

Hi @meenalkb,

looking at your files I see some files compiled in the build-wrapper-dump.json file but not the ones belonging to your SonarQube project listed in the sonarlog.txt. You can check yourself in build-wrapper-dump.json file.

Is this command running a clean build?

Looking at https://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_3/SDK_Doc/concepts/sdk_c_batch_mode.htm it seems that you need to tell explicitly in the tcl file that you need to clean. I don’t know at all xilinx sdk so I let you check.

5

Hi @mpaladin,

Thanks for the tip. It looks like the files associated with the board support package are being compiled and in the json file, but not the application source files. I will investigate this and let you know if I find a solution.

1 Like
6

Hi @meenalkb,

thank you for the update, let me know if you solve the issue.

7

Hi @mpaladin

I have been able to clean-build the sources in the application project now, in addition to the BSP project sources which were being compiled previously. (I had to modify my Tcl script to include a file deletion, to remove the elf file which was being copied into the workspace, leading the tool to skip the build altogether.) The compilation log is here - xsdk_build.txt (75.3 KB)

The build wrapper log file is here - build-wrapper_log.txt (1006.6 KB) The new JSON dump - build-wrapper-dump_json.txt (447.0 KB) - now mentions source files from the application project - although I’m not sure if it has got the full list of sources.

However, as you will see in the scanner log file, the problem still exists and 0 files have been found for analysis. sonarlog.txt (284.3 KB)

Do you think it may be the same problem as the post I previously linked, that the build is not being tracked correctly? Maybe I should attempt to just use “make”?

Kind regards

8

Hi @meenalkb,

if we consider main.c file, in the build-wrapper-dump.json file I can see compilation of file:

C:\j_Embed_SW\workspace\Signum\Signum\SignumPhoenix_app\src\main.c

If I look at sonarlog.txt file I can see that the indexed file is:

C:\j_Embed_SW\workspace\Signum\Signum MicroBlaze Xilinx SDK Project\SignumPhoenix_app\src\main.c

The paths are not the same and there is no match and that’s why you get the 0 compilation units analyzed... error. Do you have an idea of what could be happening?

9

Yes, thank you for pointing that out. Again, I think it has to do with how the Xilinx Tcl-based compilation flow works. It looks like it creates a copy of the entire project in a new area.

I’m just back on this now with a full licence and will continue to investigate the issue. Please can we leave this ticket open? Thank you.

10

Hi @meenalkb,

sure, thank you for the update.

11

Hi @mpaladin,

I worked out that the problem was there was a space in the directory name, which causes the Xilinx SDK build tool to create a new workspace (with the first part of the directory name as the workspace name)! Having fixed this has resolved the issue with the duplicated files and the flow is now up & running. Thanks for your help with the debug.

12

Hi @meenalkb,

thank you for the update!

1 Like