Hi all,
This is a big problem for my organisation also, as we use Bazel throughout and haven’t been able to fully adopt SonarQube because of this limitation.
The wrapper in question is generated from these bazel templates:
Basically, they append some env variables and possibly other options, but mostly just template in the compiler selected by the bazel toolchain (gcc, clang etc) and forward the arguments provided to it.
As for solutions:
- Is there a way to override/default which compiler is assumed by sonarqube? Can we set a setting in the vscode extension that falls back to for example clang when the compiler in compile commands isn’t recognised?
- I’ve started a PR to that specific tool with a fix that unwraps which compiler is used in compile commands - Added patch to resolve compiler from inside cc_wrapper.sh script. by Attempt3035 · Pull Request #248 · hedronvision/bazel-compile-commands-extractor · GitHub
The solution to determine which compiler is used is the equivalent of this script:
#!/bin/bash
# DEBUG & Traps need to be inherited by subshells
set -T
# shellcheck disable=SC2154
# A trap to capture the compiler command, even if it's a path to the executable
trap 'if [[ $BASH_COMMAND =~ ^[[:space:]]*(/[^[:space:]]*/)?(clang|gcc)([[:space:]]|$|[^-]) ]]; then
echo $(read -ra arr <<< "$BASH_COMMAND" && echo "${arr[0]}") # Split BASH_COMMAND into an array and read just the first element
exit 0 # End execution now that we have the compiler command
fi' DEBUG
# shellcheck disable=SC1090
# Run the passed-in script within this script's context
source "$1"
It might be good if SonarQube could implement something similar to this to attempt to query the script in question to find a suitable compiler, although I’m guessing if this happens with other tools they may have less controlled scripts which may do other unnecessary tasks when being sourced (the bazel wrapper is very simple so this works well)