Skip to content

Dependencies for host are used for target when set in grpc_deps #797

@ignasl

Description

@ignasl

I have defined and registered my own scala_proto_toolchain:

scala_proto_toolchain(
    name = "my_shiny_toolchain",
    grpc_deps = [
        "//important/dependency"
    ],
    code_generator = "//important/generator:my_generator"
)

Naturally, I am declaring the rule for proto and another scala library that depends on it:

scalapb_proto_library(
   name = "my_proto",
   deps = [...]
)

scala_library(
   name = "my_library",
   deps = [
      ":my_proto",
      "//important/dependency"
   ]
)

So dependencies are eventually set-up like this:

  1. my_proto -> //important/dependency
  2. my_library -> //important/dependency
  3. my_library -> my_proto

Now, the problem arises that when "my_library" gets built, the classpath contains two copies of the //important/dependency jars:

  1. /bazel-out/host/bin/important/dependency/dependency.jar
  2. /bazel-out/darwin-fastbuild/bin/important/dependency/dependency.jar

This is a problem, because jars meant for the host find their way into dependency list meant for the target. I cannot remove the //important/dependency' from the grpc_deps` list, because generated code requires it and this causes compile failures.

I believe (correct me if I am wrong) that bazel or rules_scala incorrectly resolves libraries' paths to host. With JVM languages compilers can happily accept them because they are essentially different. However, if this was, for example, C++ cross-platform build (host is x86 and target ARM) compiler would not allow it. Since bazel supports cross-compiling, the issue must be with scala_rules. Otherwise, please, let me know what am doing wrong.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions