Last week, we purchased sonarqube developer. I had a problem scanning the C code. I followed the steps of the official website strictly, but there were problems that I could not handle. I’ll give you the screenshot of my error and relevant information. Can you help me solve this problem?
sonarQube Version: sonarqube-9.6.0.59041
I originally wanted to use build-wrapper.log and build-wrapper-dump JSON files are sent out, but they are too large. The website does not support such large data. If you want to check, which part do I need to cut?
In another project, I encountered the same problem.
I think like this: the C & C + + language has a huge SDK, and the code we develop is only a small part, so we must specify that only a few code paths should be scanned, otherwise we will fall into endless bug false positives. But at this time, the build wrapper can’t parse out the relevant path, resulting in the inability to scan the file when the sonar scanner scans. At this time, the problem arises in the build wrapper?
Of course, it may also be my own configuration problem. Have you encountered similar problems?
This time, build-wrapper-dump.json and build-wrapper.log is also very large, and it is impossible to paste the file into the web page. If it is convenient, is there any other way to contact and communicate?
The third project has the same problem. This time, his log and JSON file are relatively small. I can upload them. You can refer to this reply directly.
#.gitlab-ci.yml
sonar_scan_analyze:
script:
- sh ci/sonar_scan_analyze.sh
only:
- schedules
- master
hi
I don’t have any smaller projects on hand at present. This is the gitlab CI log of the third project and sonar-scanner -X
You don’t have to care about tput: No value for $TERM and no -T specified. This problem is caused by the lack of interactive shell in gitlab Ci, which does not affect the successful compilation of the project.
Thank you for your answer! gitlab-ci.log (1.1 MB)
We think we understand what is the problem. Usually, during the build, the source files that you checked out are directly compiled, and we use that information to know how to analyze them.
In your case, your build process seems to work a little bit differently. Instead of directly compiling your .c files, it does a 2-steps process:
It first generates a file that contains the output of the preprocessor applied to your source file (with a .c.c extension), by launching the compiler with the -E command line option.
It then compiles this preprocessed output
The build-wrapper-dump.json correctly tracks those two steps, but then the following problem happens:
When we find a command that contains the -E option, we skip it, because we are only interested in real compilation
When we find a command that contains the real compilation, we skip it, because it applies to a temporary file that is not part of your source code
So, all in all, we skip all files, and don’t analyze anything.
How can this be solved?
Maybe the best option is to revisit why you are compiling using this unusual 2-steps process. If you used a traditional build process, in addition to the fact that we would be able to analyze your code, there is a chance that you would get a faster build, because preprocessed files are notoriously large and cumbersome.
If the first option is not feasible to you, there might be a workaround: You can write a script that, after the build-wrapper-dump.json is generated, removes from it all the "-E", lines that it contains. The resulting json should look similar enough to the json that would be generated with a single-step compilation.
Very nice! Thank you for your reply. Deleting the -E parameter successfully solved my problem. Thank you for your professional answer.
In addition, most of our company’s C / C + + code is based on IOT projects. there are many project groups and many compilation types are not uniform. I think, most of sonar’s implementations are application, the types are relatively uniform, right?
It’s hard to say because most of our users don’t tell us exactly what kind of code they analyze, but we have many questions coming from developers who use compilers for embedded software.
Thank you again for your professional reply, which helped me solve the problem that has plagued me for two weeks. So far, I have no new questions, and this problem can be closed.