-
-
Notifications
You must be signed in to change notification settings - Fork 287
Description
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:
my_proto->//important/dependencymy_library->//important/dependencymy_library->my_proto
Now, the problem arises that when "my_library" gets built, the classpath contains two copies of the //important/dependency jars:
/bazel-out/host/bin/important/dependency/dependency.jar/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.