We are scanning a C project but only ever seeing code duplication code smells reported instead of the wider range of issues we expect to see.
We are using a trial license of SonarQube Developer Edition 7.8. We have a multi-repository C project using gradle to run the build and a version of gcc targeting an embedded ARM architecture. There is a main repository that the build is run from and we git clone a few subfolders where most of the source resides. Those subfolders are listed in the main project’s .gitignore folder. Our development platform is macOS.
We used the build wrapper to run the build from the main project and then ran the command-line sonar-scanner in each cloned repository with its own sonar-project.properties file. This uploaded to our server and produced an analysis, but only showing the code duplication code smells. We noticed after the fact that our build-wrapper-dump.json file was empty:
# (C) SonarSource SA, 2014-2019, info@sonarsource.com
# All SONARSOURCE programs and content are copyright protected.
# SONARSOURCE and SONARQUBE are trademarks of SonarSource SA. All rights are expressly reserved.
#
# This file is designed exclusively for use with the SONARSOURCE C / C++ / Objective-C Plugin.
# It may not be used in connection with any other software.
# Any other use is prohibited by law and may be grounds for immediate termination of your License.
{
"version":0,
"captures":[
]}
Does anyone know why this may be the case? I assume it is the reason why we are not seeing full results. We did test an Objective-C project using XCode build and saw complete build-wrapper output and analysis.
are you running gradle in daemon mode? If yes, build-wrapper is not able to follow created processes.
You should launch gradle with --no-daemon option and see if build-wrapper-dump.json file gets populated.
It appears I am experiencing the same issue and the problem is the name of my compiler. We are using a version of gcc included as part of MCUExpresso from NXP. The full name of the compiler is ‘arm-none-eabi-gcc’. I tested creating a symbolic link ‘gcc’ to existing the compiler and confirmed that we now see proper analysis.
Unfortunately, renaming or creating symbolic links to the compiler is not a great long-term solution for us. What is the process for requesting additional compiler support built into build-wrapper?
I would also like to put my support behind a clean way to “whitelist” additional compilers. I saw your reasoning for not doing this in the thread that I linked. However, it can be worked around by renaming or sym linking anyway. Direct whitelisting via parameters or properties would certainly be a better experience for users with legitimate use cases.
Thanks for confirmation that our compiler is supposed to be detected. We ensured that we were using the --no-daemon parameter for gradle with our unmodified toolchain and we are seeing correct scans. Things are working well now.