bazel query rdeps broken for Objective-C with latest release (0.4.5)

[salguarnieri]

Please provide the following information. The more we know about your system and use case, the more easily and likely we can help.

Description of the problem / feature request / question:

We use bazel and phabricator for out project (http://kythe.io). Our presubmit executes a bazel query to find the tests that need to be executed. We have some Objective-C targets in our repository. Now with bazel 0.4.5 we get the error seeing in the reproduction below. Note that I've reproduced this using the bazel examples repository to make sure that it wasn't because of our slightly custom setup in Kythe.

If possible, provide a minimal example to reproduce the problem:

git clone https://github.com/bazelbuild/examples.git
cd into repo
bazel query 'rdeps(//..., set(...))'

Produces this output:
ERROR: examples/tutorial/ios-app/BUILD:8:1: every rule of type objc_binary implicitly depends upon the target '//tools/objc:header_scanner', but this target could not be found because of: no such package 'tools/objc': BUILD file not found on package path.

ERROR: examples/tutorial/ios-app/BUILD:18:1: every rule of type objc_library implicitly depends upon the target '//tools/objc:header_scanner', but this target could not be found because of: no such package 'tools/objc': BUILD file not found on package path.
ERROR: Evaluation of query "rdeps(//..., set(...))" failed: errors were encountered while computing transitive closure.

Environment info

• Operating System:
  OS X, Linux

• Bazel version (output of bazel info release):
  0.4.5

[salguarnieri]

To fix the kythe setup, I did this change: https://phabricator-dot-kythe-repo.appspot.com/D1441 but it seems like that shouldn't be necessary.

[hermione521]

Confirmed

[c-parsons]

This was fixed in commit 41aa37270a87e61bdf739284602842d6a23f94d1

[Steve-Munday]

@c-parsons, @hermione521: I think this was closed prematurely. I also experienced this problem in my iOS app/bazel build. I just reproduced this using the suggested steps above.

Also, the commit that was referenced was made on Feb 6th, is on master and was shipped in 0.4.5, which OP listed as the version that he was running. If anything that commit may have caused this issue, but it did not resolve it.

Environment info

Operating System:
MacOS Sierra 10.12.2

Bazel version (output of bazel info release):
0.4.5, also built from source at 3d4db19b047e921226bd3f20dd382de31eacc958

Log

~/Documents/examples/tutorial: master$ bazel query 'rdeps(//..., set(...))'
ERROR: /Users/stevemunday/Documents/examples/tutorial/ios-app/BUILD:18:1: every rule of type objc_library implicitly depends upon the target '//tools/objc:header_scanner', but this target could not be found because of: no such package 'tools/objc': BUILD file not found on package path.
ERROR: /Users/stevemunday/Documents/examples/tutorial/ios-app/BUILD:8:1: every rule of type objc_binary implicitly depends upon the target '//tools/objc:header_scanner', but this target could not be found because of: no such package 'tools/objc': BUILD file not found on package path.
ERROR: /private/var/tmp/_bazel_stevemunday/0fb7a1e8b60d8f643a54e6f2a99b121d/external/bazel_tools/src/tools/android/java/com/google/devtools/build/android/dexer/BUILD:3:1: no such target '//external:android/dx_jar_import': target 'android/dx_jar_import' not declared in package 'external' defined by /Users/stevemunday/Documents/examples/tutorial/WORKSPACE and referenced by '@bazel_tools//src/tools/android/java/com/google/devtools/build/android/dexer:dexer'.
ERROR: Evaluation of query "rdeps(//..., set(...))" failed: errors were encountered while computing transitive closure.

[c-parsons]

Indeed -- sorry about that. I've indeed reproduced this breakage. I was mistaken about this being fixed in that commit.

Looking into this now.

[Steve-Munday]

hi @c-parsons, is there any update on this?

[c-parsons]

No updates.
We currently have this filed as a p3, which is a pretty low priority.. I may not get to it this week.

In the interest of understanding if this priority is appropriate: What are your current needs for rdeps?
Is rdeps not working for any of your targets, or is it only failing when you call rdeps on your entire workspace tree like as given in the example?

[Steve-Munday]

Sure thing. So in our environment we run bazel on Jenkins for our CI, using a custom variant of https://github.com/bazelbuild/bazel/blob/master/scripts/ci/ci.sh. We have many apps in a mono repo, some iOS, Android and others. Often they are not all required to rebuild.

On each pull request to our repo, the script uses git commands to get the list of all files affected by the PR, then uses a bazel query to identify which targets to build, then builds those. See below:

# Rebuild all buildables
buildables=$(bazel query --order_output=full --keep_going --noshow_progress "kind(binary, rdeps(//..., set(${files[@]})))")
build_status=0
if [[ ! -z $buildables ]]; then
    echo "Building binaries: $buildables"
    while read -r line; do
        echo "======================================================================================"
        echo "=====  Building target: $line"
        echo "======================================================================================"
        bazel build $line
        if [[ $? != 0 ]]; then
            build_status=1
            echo "Build Failed!"
        fi
    done <<< "$buildables"
fi
readonly build_status

This query now fails every time, and the CI script completes without ever building anything.
So I am blocked from upgrading bazel in our environment unless: a) this issue is resolved, or b) I write a workaround in our CI script to just list targets directly, avoiding the query.

For now I can modify our build script, it just won't automatically pick up any new targets, and may rebuild things that are unnecessary, but hopefully bazel itself should prevent that.

[StevenEWright]

I define custom build rules in //tools/build_rules/*.bzl and have this same problem building with the new ios_application from build_bazel_rules_apple//apple:ios.bzl I'm using bazel at head with tulsi.