Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect reference to @remote_java_tools_linux//tools/jdk in @bazel_tools//tools/jdk:proguard #9116

Closed
cgruber opened this issue Aug 7, 2019 · 9 comments
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Rules-Java Issues for Java rules

Comments

@cgruber
Copy link
Contributor

cgruber commented Aug 7, 2019

Description of the problem:

When executing: bazel query 'deps(//...)'.

The following error occurs, both in 0.28 and 0.27 and 0.29 rcs. (it's fine in 0.26)

ERROR: /private/var/tmp/_bazel_gruber/3f8511af2a1bd2e817b9401d1ab7b770/external/bazel_tools/tools/jdk/BUILD:252:1: no such package '@remote_java_tools_linux//tools/jdk': BUILD file not found in directory 'tools/jdk' of external repository @remote_java_tools_linux and referenced by '@bazel_tools//tools/jdk:proguard'

digging in, the remote_java_tools_linux workspace is created, and includes lots of tools like singlejar, ijar, jacoco, and proguard, but there is no tools/jdk/BUILD in that workspace. There is a build file in the root, so @remote_java_tools_linux//:proguard would have worked, but the @bazel_tools//tools/jdk:proguard target is specified as:

alias(
    name = "proguard",
    actual = select({
        "//src/conditions:darwin": "@remote_java_tools_darwin//:proguard",
        "//src/conditions:darwin_x86_64": "@remote_java_tools_darwin//:proguard",
        "//src/conditions:windows": "@remote_java_tools_windows//:proguard",
        "//src/conditions:linux_x86_64": "@remote_java_tools_linux//:proguard",
        # On different platforms the linux repository can be used because the
        # proguard deploy jar is platform-agnostic.
        "//conditions:default": "@remote_java_tools_linux//tools/jdk:proguard",
    }),
)

This happens on both our CI machines (linux) and on my mac (darwin) which suggests that something about the platform information is off, causing it to drop to the conditional default - which is mis-specified.

Using the bazel build, test and run doesn't invoke this behavior, leading me to believe that bazel query is failing to properly set the platform information, causing the fall-through behavior, instead of hitting the proper platform conditional. So there are two issues to fix here. (a) the conditional default target needs to be corrected, as it refers to a non-existant packaget and (b) the query behavior needs to set the platform properly.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

  1. Create a workspace
  2. In 0.27.x and 0.28.x run bazel query 'deps(@bazel_tools//tools/jdk:proguard)'

What operating system are you running Bazel on?

Replace this line with your answer.

What's the output of bazel info release?

0.29.0rc4
0.28.0
0.27.1

Have you found anything relevant by searching the web?

No.

Any other information, logs, or outputs that you want to share?

No

@cgruber cgruber changed the title BUILD file missing in generated workspace @remote_java_tools_linux Incorrect reference to @remote_java_tools_linux//tools/jdk in @bazel_tools//tools/jdk:proguard Aug 7, 2019
@katre
Copy link
Member

katre commented Aug 7, 2019

bazel query is deliberately unaware of configuration: when query hits a select it effectively chooses all options. If you want a configuration-aware query, use cquery.

The invalid label is a problem which needs to be fixed. Assigning to the Java team to decide if it's a release blocker.

@katre katre added team-Rules-Java Issues for Java rules untriaged labels Aug 7, 2019
@cgruber
Copy link
Contributor Author

cgruber commented Aug 7, 2019

That's fair (re configuration). I've noticed there are a bunch of older references in default conditionals in that BUILD, particularly in legacy toolchains.

@cgruber
Copy link
Contributor Author

cgruber commented Aug 7, 2019

Also, the bazel query 'deps(//...)' is rather insane, and is an erroneous artifact of how we do an effective-tests query (an abstraction gone a little awry). But I can see query invocations against android targets hitting proguard like that.

@iirina iirina added P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels Aug 21, 2019
@iirina
Copy link
Contributor

iirina commented Aug 21, 2019

Thanks for filing the issue. I sent the fix in #9217.

@nkoroste
Copy link
Contributor

Looks like I'm still getting this issue on 0.29.0:

bazel query "deps(//platform/transition/sample:transition-sample)"
ERROR: /private/var/tmp/_bazel_n.kor/746ab4e185baab08f5cacf7da3fa6a6b/external/bazel_tools/tools/jdk/BUILD:254:1: no such package '@remote_java_tools_linux//tools/jdk': BUILD file not found in directory 'tools/jdk' of external repository @remote_java_tools_linux and referenced by '@bazel_tools//tools/jdk:proguard'
ERROR: Evaluation of query "deps(//platform/transition/sample:transition-sample)" failed: errors were encountered while computing transitive closure
Loading: 54 packages loaded

@iirina
Copy link
Contributor

iirina commented Sep 10, 2019

The fix is landing in bazel 1.0.

@salim-boudriiya
Copy link

hi,

I have the following error when I want to get the dependency graph.

ESPC006863:main smba$ bazel query 'deps(bazel_app1)' --output graph > graph.in
Loading: 0 packages loaded
ERROR: /private/var/tmp/_bazel_smba/9a5a87650c7d8a3654767232fe13fd82/external/bazel_tools/tools/jdk/BUILD:254:1: no such package '@remote_java_tools_linux//tools/jdk': BUILD file not found in directory 'tools/jdk' of external repository @remote_java_tools_linux and referenced by '@bazel_tools//tools/jdk:proguard'
ERROR: Evaluation of query "deps(bazel_app1)" failed: errors were encountered while computing transitive closure

Any one can help me please to fix it.

Best regards

@iirina
Copy link
Contributor

iirina commented Oct 1, 2019

Hi @salim-boudriiya the fix for the error you're getting is submitted and lands in the next bazel release (bazel 1.0).

@salim-boudriiya
Copy link

Thank you Irina,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Rules-Java Issues for Java rules
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants