Debugging select / config_settings?

[thomp...@google.com]

I'm having an issue where --configs are somehow dropped when building dependencies of a target.

Example:

cc_library target A has cc_library target B as a dependency, and B has a select statement with no default (so it fails if no config_setting is matched).

I can do:
bazel build --config=some_config //path/to/B
and this works fine. If I do:
bazel build --config=some_config //path/to/A
I get an error saying B could not compile because the selector did not match any config_settings. Neither B nor A appear to have any other WORKSPACE/bazelrc files that might conflict here, and B is a direct dependency of A. I would expect both to succeed or both to fail so this is puzzling to me.

Are there any pointers on debugging select statements in BUILD rules? Preferably, something that allows me to verify what configs are present when building dependencies? Is there something obvious I'm missing that could explain this behavior?

I'm currently using bazel 0.16.0 but have tried up to 0.17.1 (upgrading further would require more complicated migration work but I'd be happy to try if this was a problem with an older version of bazel).

[Greg Estren]

That indeed doesn't make sense.

What does bazel cquery --config=some_config "somepath(//path/to/A, //path/to/B)" show? The hashes on the right should match if the targets have the same --config.

You can go even farther and try

$ bazel cquery --config=some_config //path/to/A

$ bazel cquery --config=some_config //path/to/B

to see if those hashes match too.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/db688637-00d5-4b9e-b44e-6beddd4fb5cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[thomp...@google.com]

I can only do cquery on //path/to/B, because cquery on //path/to/A or somepath results in the same error (selector couldn't match any config_settings).

[Greg Estren]

1) Can you comment out the select() on B or add a default condition before the query, so you can at least get cquery results?

2) Can you share some repro case so I could see what's going on more specifically?

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/12f3d6c7-9213-4dea-9d2a-5e2a67f8d499%40googlegroups.com.

[Gregg Reynolds]

On Fri, Feb 1, 2019, 12:55 PM 'Greg Estren' via bazel-discuss <bazel-...@googlegroups.com wrote:

1) Can you comment out the select() on B or add a default condition before the query, so you can at least get cquery results?

Fwiw, I've found it useful to always use default = "BORKED" or ["BORKED"]. What's best practice?

Gregg

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CABdTCQW-E-3vL7QQ_2nwC21LNWBZKuhMxajJjy%3D44m0-ROqvyw%40mail.gmail.com.

[thomp...@google.com]

Sorry about the delay! Commenting out the conditions does result in cquery results returning consistent hashes on //path/to/A, //path/to/B, and somepath(//path/to/A, //path/to/B).

I'm working on getting a repro case, might be a while to untangle things to find a reasonably small subset that exhibits the problem.

Josh

[thomp...@google.com]

Working on minimizing a repro case ended up being pretty beneficial, because I noticed something important.

Although A had a dependency on B, the direct dependency wasn't the problem. There are many longer paths where A had a dependency on B, which I only found by whittling/culling dependency targets until I found the exact build target that failed to compile.

What was really happening is we made a skylark rule defining an implementation for a grpc proto library, and it looked like:

_proto_gen = rule(
attrs = {
...
"protoc": attr.label(
cfg = "host",
executable = True,
single_file = True,
mandatory = True,
),
"blahblah_config": attr.label(
# no cfg="host" !!!
allow_files = True,
single_file = True,
mandatory = True,
),
...
},
...
)

Adding cfg=host to the attribute that was being used made everything work perfectly fine. This would have been a bit easier to debug if I could have seen something analogous to a build stack trace, which could have pointed me to the offending rule quicker. Is there some command or flag like that?

[Greg Estren]

No, I don't think build errors are sophisticated enough (yet) to pinpoint which version of the target is failing. But it's a good point and I think more precise messaging would help as scenarios like this are more common.

In the meantime, if you have Graphviz you can do

$ bazel query 'allpaths(//testapp:mybinary, //testapp:mylib)' --output=graph | dot -Tsvg -o /tmp/query.svg

and open up the result in Chrome:

So this helps see what's going on.

cquery also supports showing the attributes that cause the dependencies, although the details are a bit tricky:

$ bazel cquery 'somepath(//testapp:mybinary, config(//testapp:mylib, host))' --transitions=lite

(if you cqueried on "somepath(//testapp:mybinary, //testapp:mylib" it would show a different path. See the docs for more info).

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/0263c857-4066-4f1b-849f-28e2d7d749ee%40googlegroups.com.