gcc build broken by .bazelrc

[while-false]

We currently have two build lines in .bazelrc:

...
build --cxxopt='-std=c++17' 
build --cxxopt='-Werror=thread-safety-analysis' --cxxopt='-Werror=thread-safety-reference'
...

We probaly want that to be just one line. Worse however, the cxxopts in the second line are clang-specific and breaks building the package locally using gcc.

Suggested resolution is that we 1) redefine the clang toolchain such that these flags are included only when compiling with clang 2) update/add a coverage in our build tests for compiling using gcc

[while-false]

And here is another clang one from .bazelrc for the test build: --cxxopt='-fstandalone-debug'

[rjhuijsman]

The multi-line build rule was with the philosophy of "one purpose per line". So one line says "we're using C++17", and the next one says "we're enforcing thread safety". Seemed more readable and scaleable.

Not that this is the primary point of this issue. 😆

[while-false]

The multi-line build rule was with the philosophy of "one purpose per line". So one line says "we're using C++17", and the next one says "we're enforcing thread safety". Seemed more readable and scaleable.

Not that this is the primary point of this issue.

Oh, I did not know that bazel accumulated the statements in this way. I assumed that redundant build lines would redefine the build and only the latest one would count. I can however verify that one indeed gets the accumulated behavior you describe. I learned something new - thanks.

But alas, as you also mention, the issue remain.

[CodingCanuck]

@while-false can we close this? I thought that bazel built with gcc by default, so I assume we're building eventuals-grpc (now called eventuals) with gcc somehow, but I'm not sure if this referred to a build break that's not cover by bazel targets.