bazel surprising rebuilding behavior on bazel build -c opt :openroad and bazel test -c opt ...

[oharboe]

After I run bazel build -c opt :openroad, I expect bazel test -c opt ... to start testing immediately and not build any .cpp files.

However, it turns out that the configuration of bazel build -c opt :openroad and bazel test -c opt ... are slightly different. The first is with -g0 and the latter with -g.

This is suprising but makes sense. I think I would have preferred to have the build always with -g and then strip symbols for a release build, but I can understand Bazel's choice and intention here and I'm sure there some snag and edge case that I'm not considering.

So the local workflow to minimize builds when testing, should be:

1. Modify source code
2. bazel test -c opt ...
3. Rinse & repeat

Notably absent in this flow is bazel build -c opt :openroad

[hovind]

$ bazelisk cquery -c opt --output=graph 'allpaths(//test/..., //:openroad)' | dot -Tsvg -o file.svg gives me:

This reveals that some tests depend on //:openroad (0b24ccd), while others depend on //:openroad (2646c78).

$ bazelisk config
Available configurations:
0b24ccd92eac9aee30d9c3421cff5361ddbe5c98eb3ea136284156efe217cc05 k8-opt-exec-ST-d57f47055a04 (exec)
2646c780eef9dc8fac37e9c1b8ed1835783fe77977a89a4be239f50aeef4ce3b k8-opt
ab8cba103302292a2b1ba4f5816adc45d4e4bc4d1f3a0e0ddbfd94da0f3bd83b fastbuild-noconfig
d693ed2150dd70fc56dd72a6be9b5c12cb12ae44035794eefdf28449aa0ada55 k8-opt

reveals that //:openroad (0b24ccd) is built for the k8-opt-exec-ST-d57f47055a04 (exec) configuration, while //:openroad (2646c78) is built for the k8-opt configuration.

As far as I understand, bazelisk build -c opt //:openroad should not build for the exec configuration.

Diffing the k8-opt-exec-ST-d57f47055a04 (exec) and k8-opt configurations at my end gives me:

@@ -208,13 +208,13 @@
   cc_output_directory_tag: 
   compiler: null
   conlyopt: []
-  copt: [-g0, -Wall, -Wextra, -Wno-sign-compare, -Wno-unused-parameter]
+  copt: [-Wall, -Wextra, -Wno-sign-compare, -Wno-unused-parameter]
   crosstool_top: @@bazel_tools//tools/cpp:toolchain
   cs_fdo_absolute_path: null
   cs_fdo_instrument: null
   cs_fdo_profile: null
   custom_malloc: null
-  cxxopt: [-g0, -std=c++17, -xc++, -ffp-contract=off, -fexceptions]
+  cxxopt: [-std=c++17, -xc++, -ffp-contract=off, -fexceptions]
   dynamic_mode: DEFAULT
   enable_fdo_profile_absolute_path: true
   experimental_cc_implementation_deps: true

where the native bazel exec transition has added the g0 flags: https://github.com/bazelbuild/bazel/blob/master/src/main/starlark/builtins_bzl/common/builtin_exec_platforms.bzl#L341-L342

As far as I know, the solution to some of the tests not using the exec configuration would be to implement the tests using a custom Starlark rule with cfg = "exec". As for attempting to build //:openroad for the exec configuration from the command line, I don't know how to achieve that. Perhaps it would be a non-issue if the configurations did not differ (if we didn't have g0 on one configuration and not the other).

[oharboe]

@hzeller was able to cast some extra light on what is going on:

#7122 (comment)