SonarOpenCommunity / sonar-cxx

SonarQube C++ Community plugin (cxx plugin): This plugin adds C++ support to SonarQube with the focus on integration of existing C++ tools.
GNU Lesser General Public License v3.0
988 stars 364 forks source link

Create additional plugin to handle c #1078

Closed jmecosta closed 7 years ago

jmecosta commented 7 years ago

@guwirth @Bertk I was trying to analyse a c project and although the cxx plugin is able to import and analyse c code, the statistics are all showing c++ loc etc.

It would be nice if we could get the separation done via 2 plugins, both would reuse most of the stuff we have so it should not cause to much problems. See for example https://sonarqube.com/dashboard?id=squash how nice it would be if we could get the metric at least split

Just for playing I've copy paste the all cxx plugin and remand cxx to c everywhere and it worked really well now I have a c plugin. However it would be nice if this would be done in the cxx plugin.

What do you think about this?

guwirth commented 7 years ago

hi @jmecosta, I have no interest on a C plugin. The current solution is working for us. We are also using C++ compiler for C code. The only advantage is to see the issues/metrics under another language. Do you know how the commercial plugin is doing it? Is it one or two plugins? Is there a possibility to have only one plugin and use another language key depending on the file extension?

jmecosta commented 7 years ago

@guwirth there are 2 commercial plugins, but i assume they reuse most of the stuff. my idea was to do the same for the cxx plugin.

we cannot have in one project 2 plugins, i thihnk because of this: org.sonar.plugins.cxx.CxxPlugin</sonar.pluginClass> however if creating to projects sonar-cxx-plugin and sonar-c-plugin wiht same packaging it should work.

ive did a couple of tests and there must be complete separation of file extensions, language keys, repository names.

That said, the all cxx thing can be reorganized so that can reuse most stuff and reduce duplication.

Indeed, having the issues metrics under different language its a extremly important feature since when you have it you can start tailoring the quality profiles in a way that apply to c only and not c++.

Altought it currently works out of the box, based on the above i think its a great advatange to all plugin users to have both of those seperated.

guwirth commented 7 years ago

@jmecosta I'm not against it but I have no time and no need to support this.

My idea was to have two CxxLanguage (https://github.com/SonarOpenCommunity/sonar-cxx/blob/056fbb3fcad753e658d0cc0df6603edf63b25d21/sonar-cxx-plugin/src/main/java/org/sonar/plugins/cxx/CxxLanguage.java#L28) and use the one or the other depending on the file extension (or mabe only two KEYs)? But still not sure if this could work. On other places in code mostly CxxLanguage-KEY is used to set language.

jmecosta commented 7 years ago

@guwirth i understand. However in terms of support it should not be any different than c++, since the idea is to reuse the all gramar from there since we have already in compatibility mode. So i dont want to touch that.

your idea about CxxLanguage is good, but it does not work. That was the first thing i tried. The only way i could get it to work is to have a seprate plugin jar file and inside have a CLanguage defintion. That works, and should not be hard to maintain.

So it would be like this, slip the sensors into a new lib called CxxSensors, left in the sonar-cxx-plugin the files for the plugin, language, colorizer, profile. Inport the CxxSensor as lib.

copy the sonar-cxx-plugin into sonar-c-plugin and reuse everythig that the cxx is working. At this point, like rename sonar-cxx-plugin to sonar-cpp-plugin.

With this i dont think we need to have any additional maitenance. But gain by having dedicated metrics for c.

guwirth commented 7 years ago

@jmecosta think you must use sonar.cxx.cpp.xxx and sonar.cxx.c.xxx otherwise you will have an conflict with the commercial plugins. Think #353 goes into same direction.

jmecosta commented 7 years ago

@guwirth the props would indeed change a bit. your solution seems ok, however changing the props for the cxx plugin will cause eveyrone to update their props files. perhaps for the cpp cxx can still be used to be backwards compatible. for c then it would be done as you suggest.

either way it will cause conflict with any plugin that tries to use extensions cpp, cxx, c, h. etc. But thats is the case already, you cant have the commercial and community installed in same instance.

should i do a prototype for consideration?

guwirth commented 7 years ago

@jmecosta yes let's try. As far as I understand there must be a generic way to set the:

Wooks61 commented 7 years ago

Hi, I am very interested to know how this goes. The projects I am analysing are all c and no c++. So this would be excellent for me.

jmecosta commented 7 years ago

@Wooks61 the idea is to reuse eveything from C++ so that its cleared that we have c source code. We are not plaaning to improve parsing or provided dedicated checks to c. We expect the tools that you use like cppcheck provide those

Wooks61 commented 7 years ago

At the moment I'm just running the sources with sonar-runner via the properties file. I haven't used any othe tools.

jmecosta commented 7 years ago

1100 covers this issue