-
Notifications
You must be signed in to change notification settings - Fork 281
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
Don't rely on SCALA_VERSION
in phases
#1559
Conversation
7ff0262
to
5396eb4
Compare
scala/scala_toolchain.bzl
Outdated
@@ -173,6 +176,12 @@ scala_toolchain = rule( | |||
default = False, | |||
doc = "Changes java binaries scripts (including tests) to use argument files and not classpath jars to improve performance, requires java > 8", | |||
), | |||
"scala_version": attr.string( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking maybe this should be an implicit/private attribute pointing to scala_version setting (which would be exposed via toolchain provider as in this PR).
For example "_scala_version": attr.label(default = "@io_bazel_rules_scala_config//:scala_version")
I'm thinking so because actual mapping of toolchain to scala version would be done on toolchain type ie
toolchain(toolchain_type = "@io_bazel_rules_scala//scala:toolchain_type", target_setting = "@io_bazel_rules_scala_config//:3_3_1")
And there could be errors of scala version mismatch
scala_toolchain(name = "toolchain_def", scala_version = "3.3.1", ...)
toolchain(toolchain = "toolchain_def", target_setting = "@io_bazel_rules_scala_config//:2_12_x", ....)
Or at least there should be validation that version specified matches current setting value.
What do you think? Do I miss something?
Side note: looking at potential toolchain
declarations I'm thinking maybe generated config_setting
could have some prefix for example scala_version_3_3_1
so target setting would look like @io_bazel_rules_scala_config//:scala_version_3_3_1
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good observation! Updated.
Now this PR depends on #1558 (don't know if there is any way to indicate that).
ecb918e
to
9b2f52b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. LGTM. Lets get previous PR merged then merge this one.
Use a new field of toolchain, `scala_version`, instead. Its value is based on the current value of Scala version build setting. Co-authored-by: mkuta <[email protected]>
Description
Before enabling cross-build we need to review (and most likely replace) all uses of
SCALA_VERSION
. This PR reviews usage ofSCALA_VERSION
when a resolved toolchain is available.This shouldn't change any behavior.
Motivation
Originally #1290.
Partitioned from #1552.