Bazel C/C++ compilation failure with build-wrapper

Hi,

I am trying to compile C/CPP source code using bazel with build-wrapper. I am facing a compilation error when compiling with the following command

build-wrapper-linux-x86-64 --out-dir bw-output bazel --batch build --config=release --config=linux64-edge --verbose_failures --spawn_strategy=local --strategy=Genrule=local

Here is the error, I have replaced filenames with generic names
Compiling foo/bar.c failed: undeclared inclusion(s) in rule ‘//foo:foo’:
this rule is missing dependency declarations for the following files included by ‘foo/bar.c’:
‘baz.yaml.h’

The build succeeds when compiling without the local flags (i.e. sandboxed)

build-wrapper-linux-x86-64 --out-dir bw-output bazel build --config=release --config=linux64-edge --verbose_failures

I assumed, local and sandbox should work similarly interms of dependency handling, but here sandboxed build works fine but local build fails.

Steps I have tried already after googling the dependency issue,

  • Created cc_library for the dependent header and declared it as deps in rule ‘//foo:foo’
  • Pass the dependent header as hdrs in rule ‘//foo:foo’
    None of the above helped.

Here are some details about my build machine
OS: Ubuntu 18.04
Bazel: 4.0.0
SonarQube build-wrapper: 6.20
Sonar-scanner: 4.6.2.2472

Hi,

Welcome to the community!

Would you mind sharing what version of SonarQube you’re using? I can’t quite backtrack from your build-wrapper version number.

 
Thx,
Ann

Hey Ann,

Thanks for the warm welcome.

The SonarQube version is 8.9.6

Regards,
Ujwal

Hi @ujwalp ,

is the build without sandbox also failing without build-wrapper?

bazel --batch build --config=release --config=linux64-edge --verbose_failures --spawn_strategy=local --strategy=Genrule=local

Could you also try by adding --bazelrc=/dev/null argument?

build-wrapper-linux-x86-64 --out-dir bw-output bazel --batch build --config=release --config=linux64-edge --verbose_failures --spawn_strategy=local --strategy=Genrule=local --bazelrc=/dev/null

If you are not able to get the non-sandboxed build working we can look at an alternative way but it would be much better if you would be able to get the non-sandboxed build working.

Hey @mpaladin ,

Yes the build without sandbox fails without build-wrapper too.

When adding --bazelrc=/dev/null using

build-wrapper-linux-x86-64 --out-dir bw-output bazel --batch build --config=release --config=linux64-edge --verbose_failures --spawn_strategy=local --strategy=Genrule=local --bazelrc=/dev/null

It says

ERROR: --bazelrc=/dev/null :: Unrecognized option: --bazelrc=/dev/null

Hi @ujwalp ,

what version of bazel are you using?

Did you make any progress in trying to get the build successful in non sandboxed mode?

Hi @mpaladin ,

I am using bazel version 4.0.0 (but specific to my org)
I am still not able to build in non-sandboxed mode.

Hi @ujwalp ,

according to User's guide - Bazel 4.0.0 --bazelrc should be available.

You have a couple of options:

1 Like

Hey @mpaladin ,

I was able to push data with the JSON Compilation Database work-around. Thanks much for the help. I will continue to work on trying successfully build in non sandboxed mode.

1 Like

Hi @ujwalp ,

thank you for the notification and glad that you managed to move forward.

Hey @mpaladin ,

I am now able to compile with sandbox disabled. But seems like the build-wrapper-dump.json genered is a pretty small file ~5k lines, compared to previous case where it was ~500k lines.

Command used

build-wrapper-linux-x86-64 --out-dir bw-output bazel --batch build --config=release --config=linux64-edge --verbose_failures --spawn_strategy=local --strategy=Genrule=local

Let me know if you need specific details from the dump json.

Thanks,
Ujwal

Hi @ujwalp ,

did you have a look at the two files to see if there is a clear difference? You can also try to analyze the project with the two files and compare the sonar-scanner output log. If you do you can eventually share the output privately and I can also have a look.

Hey @mpaladin

Lets discuss it privately.

For the records, @ujwalp managed to properly configure the analysis.

1 Like