-
Notifications
You must be signed in to change notification settings - Fork 208
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
Refactor compiler configuration repositories #900
Conversation
This makes multiple kotlin version interactions more difficult, if not impossible. This is a common usecase for burgeoning mono-repos. It's come up with java numerous times, and I've seen it a few other places. The repository approach was chosen to allow providers (and common code) to live in the core repo, while versioned code can reference that and reuse as necessary. Flattening it means that only a single version of kotlin can be accessible at a time. That said, the capabilities work is much better than the opts kludge. |
* Convert strings to label with the correct repository. * Convert label to string before passing to register_toolchains * Add labels to select * Stringify Labels to support older bazels
I'm guessing bzlmod hates the idea of multiple-repos in a module. Of course, much of this was to work around the lack of bzlmod... erg. |
bzlmod controls versions "transitively". In the graph of repository/module dependencies you can have several modules depend on Kotlin rules and maybe even Kotlin compiler. bzlmod will select a single version (of rules and compiler) for all of them. Top level module can choose to additional control/override the versions, but not versions that specific modules use. I'm not sure how would multiple versions of Kotlin play together. Everything is fine until Kotlin rules don't interact / depend on each-other. If any interaction happens, let's say two Kotlin libraries depend on each other, but have a different version of Kotlin rules. The problem would be 2 different versions of providers. Starlark would say that those are not the same provider and prevent those dependencies to be made. The interaction might be a bit better using 2 different versions of a compiler, providing they use the same conventions. But in general I think it's a bad idea to use 2 versions, either with bzlmod or in a monorepo. In principle you can't ask bzlmod from Kotlin rules, what version of the compiler you've got and then create from it a second helper repository/extension. Another thing that can happen now is, that the interface for |
There are two more things to mention. With bzlmod toplevel module can set 2 different (or multiple) versions of Kotlin compiler for specific users - that's a feature envisioned to break diamond dependency problem. And also toolchains could be used to support several versions of the compiler at the same time. |
I had a few minutes to think this over while sitting in SLC airport.... (oi.) This approach is fine (actually, it's substantially better), with a few tweaks. The I have a few notes on the layout...
|
@@ -1,5 +1,19 @@ | |||
load("@dev_io_bazel_rules_kotlin//src/main/starlark/core/options:derive.bzl", "derive") | |||
load("@dev_io_bazel_rules_kotlin//src/main/starlark/core/options:convert.bzl", "convert") | |||
# Copyright 2022 The Bazel Authors. All rights reserved. |
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.
Move to src/main/starlark
and import from there.
@@ -0,0 +1,125 @@ | |||
# Copyright 2022 The Bazel Authors. All rights reserved. |
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.
Move these to a capabilities
directory? It's getting crowded in here.
This simplifies the option resolution for head. Multiple kotlin toolchains can be more simply handled via bzlmod.
This simplifies the option resolution for head. Multiple kotlin toolchains can be more simply handled via bzlmod.
This simplifies the option resolution for head. Multiple kotlin toolchains can be more simply handled via bzlmod.
Any update on this PR? |
Implemented in #963 |
Add
capabilities.bzl
to Kotlin compiler repository. Generatekt_kotlinc_options
rule from it, that is filter out options that are not available in a specific version.This change makes a narrow interface between Kotlin compiler and Kotlin rules. It will make it possible to release and use new versions of Kotlin compiler independently from Kotlin rules.
The release of Kotlin compiler should include the new
capabilities.bzl
file.The
capabilities.bzl
files were generated by grepping respective version of Kotlin compiler sources for@Argument
annotation (some of them are not documented). Thelegacy
file was generated from Kotlin compiler 1.3.0 additionally removing options that weren't available insrc/legacy
.There are some minor differences from previous
src/legacy
- javac opts are the same for versions.Works toward: #660