sonarqube 4.5 has misidentified a cpp module as c - how can I fix it - sonarqube

I created a multi-module project with a single sonar-project.properties. Most of the project is in c but one module is c++. I left the sonar.language property blank and ran sonar-runner with analysis.
The project and modules were created in the database and everything looked OK but when I did a preview on the same code I had a large number of new issues on the c++ project.
On closer inspection I found that the module in sonarqube was all wrong - it consisted of only the header files (.h) and most of the issues were the use of C style comments. It seems that the module was identified as a C module so all the .cpp files were ignored. However, in the preview the language was identified correctly and issues were found in the .cpp files that were clearly not know to sonarqube.
I cannot find any place in the UI to change the language of a module nor can I figure out a way to force it after the fact in my sonar-project.profiles.
First, sonar.language is apparently deprecated, and second, using module.sonar.language=cpp caused an error:
Caused by: sonar.profile was set to 'DEFAULT_C' but didn't match any profile for any language. Please check your configuration.
DEFAULT_C is something that we use for projects generally but not the one I'm working on. I have different profiles set up for different languages via the UI, but if I cannot get the analysis to see the correct language it doesn't help me much.
Any one have any idea how I can force the language of a module after the fact?

Hmm. I considered just deleting this but if I had found an answer on stackoverflow it would have eased my pain a little.
Brute force works.
Just set the language and the profile you want for the moudle and ignore complaints about such things being deprecated. Chosing a language won't force the right profile even if you have set up an explicit profile for the language in the UI - so just state it in the sonar-project.properties file.
In my case:
module.sonar.language=cpp
module.sonar.profile=MY_CPP_PROFILE
Throw sonar-runner at that and it will beat the backend into shape.

Related

Multiple Metal shaders with different language versions in one project

I'm trying to include multiple Metal shaders in my Xcode project which have different language versions, but I'm unable to figure out how to do it.
I'm trying to do this, so I can support the latest features when available and drop back when not.
In the project's settings I can only find a general specifier for the Metal language revision. I also can't find anything in the MSL reference manual to specify it inside the file.
Is this even possible? If so, how?
Thanks in advance.
In Xcode, go to the Build Phases for the target which builds your app. Disclose the compile sources. Select a .metal file. Double-click in the right-hand Compiler Flags column to edit it. Enter -std=osx-metal1.2 or similar. That specific shader source file will be compiled with that language.
I found this compiler flag by comparing the build transcripts of builds with various settings for the target-wide build setting.

C++ Builder 2009 - i18n - Quick Reports Exception - Class TQRPDFFilter not Found - When Change Format

Using Win7, C++ Builder 2009 I have a project that I am able to compile and run without any issues when my region and language format is set to "English (United States)".
When I change the format to "Italian (Italy)", my program compiles then I get an exception that "Project .exe raised exception class EClassNotFound with message 'Class TQRPDFFilter not found'."
Nothing else changes in the program or paths, just the system change and I get this exception. I checked both the include and lib paths and they are setup correctly.
Its been a while since I asked this question. I'm following up, just as a reference. I believe the issue was based on the import paths our projects use. We have a "common" set of code which is shared between some projects. The common source has references to TQRPDFFilter where the specific project does not. By changing the path order, putting common at the least priority, I got past my problem. This does not answer the question as far as why it was blowing up with the different language, but might give some insight to others on how to get past it, if they come across similar setups.

How to specify library paths for sonar-runner with C code

I am trying to set up sonar-runner on a legacy code base. It seems to be working. However, I get several warnings like this:
WARN #include the file filename1.h could not be found at file:filename2.h. Please check your additional library configuration.
I found a property I can possibly set in the sonar-project.properties file to point to all the library directories:
sonar.c.library.directories=/path/to/library/
My problem is, there are seriously about 50 directories I will need to include to capture them all, and as far as I can tell, I need to type them all on a single line, comma-separated.
So, my question is,
is it worth it?
Does sonar-runner need to find these dependencies to do an appropriate analysis? Would I gain anything at all, or should I just let it be?

Maven flex project using source directory from seperate module with new artifactId

Finding it difficult to express myself easily around this issue so thought best to start with a context section:
Context:
I have a Flex based application (a rather complex system) that can be compiled using "conditional compilation" into various use cases eg:
Compilation One = portalProjectUserOne
Compilation two = portalProjectUserTwo
Whether using conditional compilation is a sound idea is a completly different argument and therefore lets assume one is forced down this road, I then however decide to create a project for each of my desired compilations:
portalProjectUserOne
-branches
-tags
-trunk
-src
-pom
portalProjectUserTwo
-branches
-tags
-trunk
-src
-{NEEDS TO USE PROJECT ONES SOURCE}
As I do not want to break the ever rigid laws of programming and not duplicate anything I need a way of accessing the source of project ONE and using the source to do a CUSTOM compilation.
Things I have tried:
I tried using relative paths (../../portalProjectUserOne/trunk/src/etc...) with successful compilation but when it came time to release a final product to the nexus repo it had a few issues with reaching out the project structure, that and it felt a bit dirty really.
I attempted to use the "maven-dependency-plugin" to try and copy the sources from the first project, maybe this a pure lack of understanding on my part but I can not get my head around how you generate your classes in one project and access them from another.
This is my first question on stackoverflow and if I have been far to broad please let me know and I shall update with more extensive examples if required.
Thanks for listening/reading/being a coder.

Custom building SGEN assemblies and including in installer

I've been rather confused by some SGEN stuff. I've enable the generation of serialization assemblies for one of my projects. Originally I got the follow error which I believe I've solved by doing some caspol stuff on a remote assembly.
Unable to load one or more of the request types. Retrieve the
LoaderExceptions propery for more information
Now however, I don't get an assembly generated. Adding some debugging/verbose output provides the message "SS.dll does not contain any types that can be serialized using XmlSerializer". I've read that this is because of a proxy switch applied by VS. The odd thing is it doesn't seem to be a problem with any other project.
So if I disable the proxy switch (example here) it seems to work. The linked build events however seem to do all projects. I don't know enough about MSBuild to tweak to just a single project, does anyone know what I need to change?
Additionally, if this change is made, is there a way I can automatically include this in a installer (VDProj)? I can't statically link to the SS.XmlSerializers.dll because the each dev uses a custom path.
Discovered the following post which talks about adding the <SGenUseProxyTypes>Off</SGenUseProxyTypes> to the csproj file which seems to work :)

Resources