CFamily: Howto add exotic Clang-Derivative?

I try to build-wrap or MSBuild a c++ project based on the Embarcadero IDE using SonarQube 7.4 and commercial CFamily plugin.
Embarcadero has derived its own compiler “bcc32c.exe” from Clang.
So, I would expect to get build-wrapper accept at least somehow the output of bcc32.exe.
The log files shows, that the process “bcc32.exe” is skipped, since it does not match any supported

Is there no configuration file to change/add exotic compilers? Is the build-wrapper source code available or is a contribution possible? I would add the support of that compiler, shouldn´t be so hard to parse clang-frontend command line switches etc.

Thanks for inspiration.

Here is a log

Mon Jan 28 15:20:58 2019: build-wrapper, version 5.1 (win-x86-
Mon Jan 28 15:20:58 2019: isWow64: 
Mon Jan 28 15:20:58 2019: windows version: 6.1, service pack: 1.0, build number: 7601, product type: 1Mon Jan 28 15:20:59 2019: skipping process C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\bcc32c.exe with pid: 
Mon Jan 28 15:21:03 2019: process with pid 7112 exit with code: 0 (
Mon Jan 28 15:21:03 2019: process created with pid: 
Mon Jan 28 15:21:03 2019: image path name: <C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\bcc32c.exe>

Hi @Alex_Na,

we don’t really support custom compilers, if you are sure that bcc32c.exe has the same interface as clang you may be able to rename it to bcc32c-clang.exe and it could work but bear in mind that this is not a supported behaviour. We officially support only the compilers listed in the analyzer page:

@Alex_Na to fully reply your questions:

There is no configuration file to change/add exotic compilers to build-wrapper and it is currently closed source which means that source code is not available and it is not possible to contribute to it.
Not allowing external configuration allow us to control what compilers to support and make sure that we properly support them in order to provide you with the best analysis result.

so far, the build-wrapper creates the json file by compiling the Embacader-Compiler (bcc64).
Unfortunately, the bcc64.exe is a 32-bit-executable itself. lol.
Therefore the 6.0-Cfamily´s subprocess.exe crashes, because I understood 32-bit-executables are not supported anymore. I ask myself why 32bit matters, when the json already shows (all?) needed information like defines, paths, flags.
I tried to install a later CFamily-plugin 5.x supporting 32bit compiler-executables.

How could I re-install previous cfamily plugin to Sonarqube server 7.5?

Hi @Alex_Na,

32 bits executables running on 64 bits operating systems are supported, what are not supported anymore are 32 bits operating systems.

What is the issue that you are facing with the new analyzer? Could you please post the sonar-scanner log? Please keep in mind that your compiler is not officially supported.

Hi Massimo
I could even provide you a minimalistic sample project, comparing the successful run using original “clang++” and that bcc64-derivate (bcc64-clang++).
How can I send you the zip archive incl. the buildwrapper and sonar-scanner used? some MiB space required.
To execute that you could install a trial-version of embarcadero or just study the json and build-wrapper-logs included.

@Alex_Na I sent you a pm.

Hello @Alex_Na,

unfortunately bcc64 even though it is based on clang it is not fully compliant and it leads to a failure on our side. As it is not in the list of official compilers we cannot promise you a fix.
However I created a ticket on dev side to add support for Embarcadero compiler: CPP-2092

Hey Massimo
thanks for your effort and interst in that case.
Meanwhile I have discussion with Embarcader as well.
Looking on their wiki, you will that the compiler “bcc32x” has better compatibiliy regarding clang-command-switches than even maybe bcc64. The Embac. is not able to explain it in all details to me, or I am too stupid…

Could you try on your site the “bcc32x” compiler once again instead of bcc64, if the result is better than a crash so far.

Thanks and nice weekend

Hi @Alex_Na,

from a quick check it looks to me that bcc32x shares the same issue as bcc64 as desscribed in CPP-2092.