We’re using bazel as our build system along with GitHub - hedronvision/bazel-compile-commands-extractor: Goal: Enable awesome tooling for Bazel users of the C language family. to extract a compilation database. The compilation database is not directly referencing the compiler that was used, but rather a build wrapper script like external/local_config_cc/cc_wrapper.sh. I’ve had to manually replace this string in the compilation database by e.g. clang++ to have SonarLint (in VS Code) work, otherwise the following log message is output in the debug messages and no analysis is done:
It would be great if there was a setting to override the compiler, or alternatively, if SonarLint tried to figure out what the compiler was based on other flags etc.
I’m using v4.18.0 of sonarsource.sonarlint-vscode .
Hello @reimerix, and thank you for taking the time to share the feedback and the suggestions with us,
The analyzer currently relies on the compiler identification to determine how to interpret the flags. It additionally needs to communicate with the compiler to retrieve some information (e.g. system include directories, …etc).
A problem that comes to mind is that the compilation database may contain different entries that use different compilers. The way I see this at the moment, is that such a setting would need to accept a map of compiler paths to remain useful in such a case, which makes it less convenient for users.
Currently, recognizing the compiler is a prerequisite to interpreting the flags (as described above). I think it is possible in theory to have a heuristic to “guess” the compiler based on the seen flags, but in some of the supported compilers, they are similar, and my concern is that it may result in confusing behavior if the guess was incorrect.
Do you know more details about the purpose of this wrapper script, and in what conditions it is used by bazel-compile-commands-extractor? For example, is it known to always wrap clang/gcc? Is it generated on all platforms? What is its purpose and how different are the flags provided to the script different from the ones seen by the compiler executable?
For example, if it is an internal implementation detail of bazel, maybe the bazel-compile-commands-extractor might be interested in “seeing through” these wrapper scripts and writing the actual command that was passed to the compiler instead?
I think that the answers to these questions may help us think about other solutions to provide better support for this case…