The cxx plugin does not run any static analysis tools, thus all reports must be generated externally

Here is a quick guide how to generate the reports using external tools

cppcheck

Make sure to pass all include directories as otherwise the analysis will be incomplete. Caveat: cppcheck writes the output to the standard error.

Rule Extensions Extension of cppcheck rules is possible by using extensions/rules/cppcheck. See Extending the Available Tools Rules on how to create the rules

cppncss

You may also use -D and -M options to tell cppncss about preprocessor macros.

Coverage

Cobertura and Bullseye (http://www.bullseye.com/) XML formats are supported for > 0.2 versions. Previous versions support only Cobertura, and sonar.cxx.gcovr.reportPath needed to be set.

Gcov / gcovr

1. 1. Make sure to compile and link with the --coverage-flag. Disable optimizations and switch on debugging.
   2. Execute your application / your tests. This will generate .gcda-files.
   3. Collect the coverage information and generate the report using gcovr:

Bullseye

Bullseye coverage tool is now supported, the command 'covxml' can be used to create the XML report. Once xml reports is available it can be imported using the properties sonar.cxx.coverage.reportPath and sonar.cxx.coverage.itReportPath.

Notes about coverage display in sonar:

Sonar <3.2 provides metrics for line coverage and branch coverage. Bullseye users have function and branch/decision coverage instead, the cxx plugin coverts the second directly into branch coverage however line coverage is far more complex and cannot be correlated directly into function coverage.

Line coverage imported from a bullseye report means than function coverage + line branch coverage ( this second occurs since sonar will not display branch coverage if there isn't a line it associated with it). This means also that overall coverage will be affect in sonar and cannot be compared directly to bullseye results. The following pictures illustrate this for a small example project.

Valgrind

Just tell valgrind to generate XML output. The 'tool' option isn't necessary as 'memcheck' is the default one. Make sure the binaries contain debug info.

Rule Extensions Extension of valgrind rules is possible by using extensions/rules/valgrind. See Extending the Available Tools Rules on how to create the rules

Vera++

The generation of vera++ reports is somewhat more tricky. We find all the files we want to be analysed, pipe this list into vera++ and pipe its output into a Perl script which finally generates the required XML. 

Rule Extensions Extension of vera++ rules is possible by using extensions/rules/vera++. See Extending the Available Tools Rules on how to create the rules

RATS

Rule Extensions Extension of rats rules is possible by using extensions/rules/rats. See Extending the Available Tools Rules on how to create the rules

PC-Lint

Please refer to product page (Official Site)

Rule Extensions Extension of pclint rules is possible by using extensions/rules/pclint. See Extending the Available Tools Rules on how to create the rules

External Tool sensor

As of version 0.2, any static analysis tool can be reused with the plugin using the property sonar.cxx.externalrules.reportPath. The following table describes the format of the report

<element name="results" xmlns="http://relaxng.org/ns/structure/1.0">
 <zeroOrMore>
   <element name="error">
     <attribute name="file"/>
     <attribute name="msg"/>
     <attribute name="id"/>
     <attribute name="line">
       <data type="integer" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes" />
     </attribute>
     <text/>
   </element>
 </zeroOrMore>
</element>

To enable the rules in sonar see