cannot find include files

[ccommissoTrust]

When running the sonar-scanner command on a c++ project I get:

cannot find the sources for '#include <acme/bar/common/Logging.h>'

I see this for all of my include files throughout my project. For reference I do have the include file in question in my repo:

find . -name Logging.h
./bar/src/common/include/acme/bar/common/Logging.h

my sonar-project.properties file has the following defined:

sonar.cxx.includeDirectories=/**/include/*.h

I also tried the following combinations. With all of them I was not able to fine Logging.h:

sonar.cxx.includeDirectories=./bar/src/common/include/acme/bar/common/
sonar.cxx.includeDirectories=./bar/src/common/include/acme/bar/common
sonar.cxx.includeDirectories=./bar/src/common/include/
sonar.cxx.includeDirectories=./bar/src/common/include
sonar.cxx.includeDirectories=./bar/src
sonar.cxx.includeDirectories=./bar/src/common/include/acme/bar/common_

Here is the entire sonar-project.properties file:

sonar.projectKey=CxxPlugin:Sample
sonar.projectName=Sample
sonar.projectVersion=0.0.1
sonar.language=c++

sonar.sources=bar/src
sonar.tests=bar/tests

sonar.artifact.path=cmake/bar/src/service/bar-service

sonar.cxx.includeDirectories=/**/include/*.h`

Im using SonarQube 5.5.6 with version 0.9.7 of the C++ Plugin. Im running sonar with the embedded Database (https://hub.docker.com/_/sonarqube/)

[guwirth]

@ccommissoTrust

cannot find the sources for '#include <acme/bar/common/Logging.h>

Angle-bracket form: the preprocessor searches for include files in the under sonar.cxx.includeDirectories defined folders and order.

Because your ange-bracket include is a relative path <acme/bar/common/Logging.h> you have to define the absolute part with sonar.cxx.includeDirectories.

Assuming that the folder of ACME is c:\sample\lib\acme\... you have to set

sonar.cxx.includeDirectories=c:/sample/lib

You have to use forward slashes!

[ccommissoTrust]

Thanks @guwirth . This unblocked me and my scan can now find include files.

Is it possible to use sonar.cxx.includeDirectories as a multiline property? I have dozens of include directories I will need to add and its very messy to keep it all on the same line. I tried splitting it into multilines similar to the way im using sonar.cxx.defines but I have had no luck. If its not possible I think that should be a feature request.

Thanks

[guwirth]

@ccommissoTrust

sonar.cxx.includeDirectories is a comma separated list of directories where the plugin will be looking for included files.

https://github.com/SonarOpenCommunity/sonar-cxx/wiki/Supported-configuration-properties#sonarcxxincludedirectories

[naderafshari]

-Dsonar.cxx.includeDirectories=./main/inc, ../hrl/inc, ../prl/inc
ERROR: Unrecognized option: ../hrl/inc,
does it need absolute paths?

[naderafshari]

It turns out that the space after comma is not good.

[ivangalkin]

Hi @naderafshari

1. one small comment from my side: sonar-cxx documentation recommends to use external reports from 3rd party analyzers. For them the internal preprocessor doesn't play any role. So you can ignore the warnings if you use cppcheck, clang, valgrind etc.
   Even for the internal checker (aka SquidSensor) the includes are used for detection of #defines only, so there is no big harm if some includes will be missing

2. you are on the safe side if you pass the includes as absolute paths, but relative paths must be ok too: I believe the base directory of the analyzed project will be used in order to make them absolute.

@guwirth we have tons of opened issues because of warnings. I believe we should address them as a whole:

• Introduce some FAQ page, where we describe which warning is important, and which is not. E.g. importing of external reports for multi-module projects might cause many warnings too (see Not able to force plugin to find files from coverage report #1508) and this is totally normal
• I think we have to lower the severity of this warning in the future (e.g. as INFO instead of WARN)
• As alternative we could make the severity context adaptive
  • Use WARN for missing includes only if SquidSensor is activated. Use INFO otherwise.
  • Use INFO for missing path in the module if multi-module project is analyzed. I mean the case where we import some huge external report independently for each module of the multi-module project (this is correct) and the mentioned paths are scattered over several modules
  • etc

W.r.t. to the issue itself: The benefit of the #include preprocessing is very questionable IMHO. As I mentioned earlier, the only aim for include preprocessing is to collect the #defines. To be honest the whole preprocessor doesn't make any big sense if we position sonar-cxx as a plugin for importing of external reports only (see the very first sentence of the documentation and #1410)

We have one more issue #1489, that also addresses the missing-include warnings. Since the preprocessor is not that needed and not really maintainable (#1500), we should start clean it up:

• lower the trace severity (? see above)
• disable #include (#if, #ifdef, macro expansion etc) if SquidSensor is not used (?)
• disable #include (#if, #ifdef, macro expansion etc) completely (?)

Should I create a US for one of above alternatives?

[guwirth]

@ivangalkin

@guwirth we have tons of opened issues because of warnings. I believe we should address them as a whole

In the past we had a lot of issues because of missing warnings. So maybe there are too much now.

I think we have to lower the severity of this warning in the future (e.g. as INFO instead of WARN)

Beforehand it's sometimes difficult to decide if an issue will afterwards be an info, warning or maybe error.
That depends what is really in use.

Use WARN for missing includes only if SquidSensor is activated. Use INFO otherwise.

My proposal in other issue was an additional interface for checks: preprocessor needed.
But open question is still how big the changes in metrics are.

W.r.t. to the issue itself: The benefit of the #include preprocessing is very questionable IMHO. As I mentioned earlier, the only aim for include preprocessing is to collect the #defines.

And impact on metrics...

Should I create a US for one of above alternatives?

Same recommendation as in other issue #1528:

Would start with this global configuration property. Maybe sonar.cxx.usePreprocessor=yes/no (default=yes)? With this setting we can play around to see the impact on the metrics.

[jmecosta]

@guwirth @ivangalkin why just reduce the WARN to DEBUG, so they are disable by default?

[guwirth]

@jmecosta in the past users were complaining that they got no warning. This was the reason to move it from debug to warn. I like more the approach from @ivangalkin to display it as warning only when we need the preprocessor (e.g. in checks).

But I think it's also an interesting approach to see if we need an preprocessor at all to get accurate results.

[guwirth]

I will make a proposal to generate only one warning at the end of the LOG file. Details will be provided only if debug info are on (same approach as #1565).

Warning:
Preprocessor can’t find all include files. This is only relevant if parser creates syntax errors.
The preprocessor searches for include files in the with sonar.cxx.includeDirectories defined directories and order.