question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

`target_compatible_with` with `genquery` fails in cases where `query` would succeed

See original GitHub issue

With this root BUILD file:

constraint_setting(name = "incompatible_setting")

constraint_value(
    name = "incompatible",
    constraint_setting = ":incompatible_setting",
)

sh_test(
    name = "bar",
    srcs = ["BUILD"],
    target_compatible_with = ["//:incompatible"],
)

genquery(
    name = "query",
    testonly = True,
    expression = "//:bar",
    scope = ["//:bar"],
)

If you run bazel build //:query you get this failure:

% bazel build //:query
ERROR: Target //:query is incompatible and cannot be built, but was explicitly requested.
Dependency chain:
    //:query
    //:bar   <-- target platform didn't satisfy constraint //:incompatible
INFO: Elapsed time: 0.075s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded, 5 targets configured)

Interestingly if you omit the //: from the target, it skips the genquery all together:

% bazel build query
INFO: Analyzed target //:query (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:query was skipped
INFO: Elapsed time: 0.100s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

If you just query this target, it works:

% bazel query //:bar
//:bar

I’m not sure what the expectations are around genquery and it’s similarity to query, but it would be ideal in this case if genquery would also succeed. Also I think the difference in behavior when you have //: or not is unexpected.

What operating system are you running Bazel on?

macOS

What’s the output of bazel info release?

release 4.0.0

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:1
  • Comments:6 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
philsccommented, Feb 13, 2021

At the very least I should fix the query vs. //:query difference. It really shouldn’t be different.

Mayber after that I’ll have my head wrapped around what the better behaviour is.

0reactions
gregestrencommented, Feb 16, 2021

You can get a similar failure even without target_compatible_with:

config_setting(
    name = "a",
    define_values = {"a": "1"})

genrule(
    name = "g",
    srcs = [],
    outs = ["g.out"],
    cmd = select({":a": "echo hi > $@",}))

genquery(
    name = "gq",
    expression = "//testapp:g",
    scope = [":g"])
$ bazel build //testapp:gq
ERROR: testapp/BUILD:8:8: Configurable attribute "cmd" doesn't match this configuration (would a
default condition help?).
Conditions checked:
 //testapp:a
ERROR: Analysis of target '//testapp:gq' failed; build aborted: 
$ bazel build //testapp:gq --define a=1
INFO: Build completed successfully, 1 total action
Read more comments on GitHub >

github_iconTop Results From Across the Web

General Rules | Bazel
Queries violating this rule will fail during execution if strict is unspecified or true (if strict is false, the out of scope targets...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found