scala_toolchain repository rule?

[johnynek]

I wonder if the solution to portability across various versions of scala would be a scala_toolchain repository rule somewhat similar to this:

https://bazel.build/versions/master/docs/be/java.html#java_toolchain

This would set up all the per-language features that need to be set up, along with any custom compiler flags to make the default in the repo.

[ittaiz]

Interesting. Do you think the "scala.dependencies.version" which we need to add to maven dependencies will be taken from there?

…

On Mon, Mar 20, 2017 at 7:53 PM P. Oscar Boykin ***@***.***> wrote: I wonder if the solution to portability across various versions of scala would be a scala_toolchain repository rule somewhat similar to this: https://bazel.build/versions/master/docs/be/java.html#java_toolchain This would set up all the per-language features that need to be set up, along with any custom compiler flags to make the default in the repo. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#170>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF0r-oG5muhJOyl_brnwTh54Nny0eks5rnr0QgaJpZM4Miyll> .

[johnynek]

Now that #171 has been merged, I think we can actually make the rules only depend on jars (since we no longer are using the scala script to launch the repl), and not downloading the big scala-sdk, which is nice since it will be a smaller download and we should be able to share those jars in a more standard way with the rest of the build.

[sdtwigg]

I support this idea.

Some random partially-coherent thoughts:

I presume this is also how we can pivot into allowing cross-compilation? (Have a macro setup a scala_library for each scala_toolchain where there is a scala_toolchain for each version of interest?)

I presume the fields would mostly be the jars supplied already in _implicit_deps, like scalac, library, reflect, etc.? In implementation, I would imagine the rules just transits all its inputs to providers? We can also provide a simple rule for building a java_binary scalac from a set of jars since all the java code should be identical with just the dependency jars changing....

How can we inject the toolchain? (I think java_toolchain can go on the command-line; however, this may be due to Bazel internal magic. Otherwise, my snap thought was a scala_toolchain argument to scala_*.)

I am on the fence about the "Scalac" mnemonic for use in the worker. Including the scala_toolchain version, e.g. "Scalac2_11" would avoid worker clobbering issues when the scala_toolchain changes across builds (or there are multiple uses of toolchain within a build). However, then specify on the commandline that workers are allowed is tedious.... Maybe the toolchain itself specifies the mnemonic for scalac. Then the default toolchain just is Scalac and other toolchains (that may be running concurrently) should specify unique ones?

[ittaiz]

I just hit this need :( Trying to run bazel on docker got me into an infamous scalac bug which can be worked by supplying "Xmax-classfile-name" as an option to scalac. Given that I don't have the toolchain I'll need to currently add it to all of my targets...

1. Am I missing something very easy other than the toolchain?
2. @damienmg any thoughts on "how to inject the toolchain"?

We'll probably take this in the foreseeable future (next month or two)

[softprops]

For scalac options, we refer to a const dict loaded from a workplace local bzl file.

[ittaiz]

@softprops I see. But then you still have to remember to pass this dict in every target right?
@johnynek / @sdtwigg any tips from your end?

[softprops]

@ittaiz its one way of sharing. Another pattern I've seen that provides a more implicit way to share settings to to define a workspace local version of a set of rules that wrap the upstream set of rules

in local_tools/scala/scala.bzl

load("@io_bazel_rules_scala//scala:scala.bzl",
     upstream_lib = "scala_library"
    )

# delegate to upstream scala_library 
def scala_library(custom_defaults_here ...):
   upstream_lib(...)

in your pkg BUILD

load(
    "//local_tools/scala:scala.bzl",
    "scala_library",
)

# now you're referring to the delegator
scala_library(
  # custom defaults will be used implicitly if not provided here
)

[ittaiz]

yeah, I think your second approach is what @johnynek said they're using. This might be ok but I don't like having to duplicate all of the properties on the one hand or losing readability if I use **kwargs.

[johnynek]

we do the the same approach. It works well. I think the toolchain is important, and maybe can help with this case (default options, default plugins) but I think you can work around.

[oscar-stripe]

note #251 is harder than it needs to be due to lack of this.

[johnynek]

https://docs.bazel.build/versions/master/be/platform.html

This seems to be the way to create toolchains.

[johnynek]

See this example for rust:

katre/rules_rust@8938db7

[ittaiz]

rust link is 404.
more permanent one:
https://github.com/bazelbuild/rules_rust/pull/52/files

[ittaiz]

more info bazelbuild/rules_docker#241 (comment)

[ittaiz]

fixed by #364