-
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
Build a compiler extension and then use it #1674
Comments
I think a |
I'd need a way to provide a different set of deps for |
Can it be solved with macros? Eg. |
I doubt it can be solved with macros. What I'd need is two different versions of scalac java_binary, one that is using one set of dependencies, and another that uses another set of dependencies. |
I managed to solve it. Steps:
This works without changing rules_scala. tools/compile-with-extensions/compile_with_extensions.bzl:
tools/compile-with-extensions/BUILD:
My macro definitions:
To compile my extension:
|
Refactor SCALAC_DEPS parameter to a Starlark file to make it reusable for users. See bazelbuild#1674 for a possible usecase.
Refactor SCALAC_DEPS parameter to a Starlark file to make it reusable for users. See bazelbuild#1674 for a possible usecase.
Refactor SCALAC_DEPS parameter and scalac target definitions to a Starlark file to make it reusable for outside users. Added: - define_scalac() - define_scalac_bootstrap() A user could do: ``` EXTENDED_SCALAC_DEPS = DEFAULT_SCALAC_DEPS + [ "@//my/compiler/dependency:library", ] define_scalac( name = "scalac_with_extensions", deps = EXTENDED_SCALAC_DEPS, ) ``` And then build that compiler library in the same monorepo, this way, providing compiler dependencies without toolchains (that would cause cycles for this usecase). See bazelbuild#1674 for more information.
Refactor SCALAC_DEPS parameter and scalac target definitions to a Starlark file to make it reusable for outside users. Added: - define_scalac() - define_scalac_bootstrap() A user could do: ``` EXTENDED_SCALAC_DEPS = DEFAULT_SCALAC_DEPS + [ "@//my/compiler/dependency:library", ] define_scalac( name = "scalac_with_extensions", deps = EXTENDED_SCALAC_DEPS, ) ``` And then build that compiler library in the same monorepo, this way, providing compiler dependencies without toolchains (that would cause cycles for this usecase). See bazelbuild#1674 for more information.
Refactor SCALAC_DEPS parameter and scalac target definitions to a Starlark file to make it reusable for outside users. Added: - define_scalac() - define_scalac_bootstrap() A user could do: ``` EXTENDED_SCALAC_DEPS = DEFAULT_SCALAC_DEPS + [ "@//my/compiler/dependency:library", ] define_scalac( name = "scalac_with_extensions", deps = EXTENDED_SCALAC_DEPS, ) ``` And then build that compiler library in the same monorepo, this way, providing compiler dependencies without toolchains (that would cause cycles for this usecase). See bazelbuild#1674 for more information.
With the latest changes from #1677,
|
I'd like to remove Scala compiler extensions from the Scala toolchain, that I could be potentially building myself (in the same monorepo, build the compiler extension, but also use it). Till now the only way to add Scala compiler dependencies was a toolchain. If I left the compiler extension as a toolchain dependency there, I could not build the compiler extension due to a cycle in deps (building the compiler extension would depend on itself through the toolchain). I'd like to work this around by defining my own scalac java_binary target, where I can define my own dependencies (and then create rule names with macros that override the scalac target). To do this without duplicating code from rules_scala, refactor SCALAC_DEPS parameter and scalac target definitions to a Starlark file to make them reusable for outside users. Added: - define_scalac() - define_scalac_bootstrap() A user could do: ``` EXTENDED_SCALAC_DEPS = DEFAULT_SCALAC_DEPS + [ "@//my/compiler/dependency:library", ] define_scalac( name = "scalac_with_extensions", deps = EXTENDED_SCALAC_DEPS, ) ``` And then build that compiler library in the same monorepo, this way, providing compiler dependencies without toolchains (that would cause cycles for this usecase). See bazelbuild#1674 for more information.
I'd like to remove Scala compiler extensions from the Scala toolchain, that I could be potentially building myself (in the same monorepo, build the compiler extension, but also use it). Till now the only way to add Scala compiler dependencies was a toolchain. If I left the compiler extension as a toolchain dependency there, I could not build the compiler extension due to a cycle in deps (building the compiler extension would depend on itself through the toolchain). I'd like to work this around by defining my own scalac java_binary target, where I can define my own dependencies (and then create rule names with macros that override the scalac target). To do this without duplicating code from rules_scala, refactor SCALAC_DEPS parameter and scalac target definitions to a Starlark file to make them reusable for outside users. Added: - define_scalac() - define_scalac_bootstrap() A user could do: ``` EXTENDED_SCALAC_DEPS = DEFAULT_SCALAC_DEPS + [ "@//my/compiler/dependency:library", ] define_scalac( name = "scalac_with_extensions", deps = EXTENDED_SCALAC_DEPS, ) ``` And then build that compiler library in the same monorepo, this way, providing compiler dependencies without toolchains (that would cause cycles for this usecase). See bazelbuild#1674 for more information.
I'd like to remove Scala compiler extensions from the Scala toolchain, that I could be potentially building myself (in the same monorepo, build the compiler extension, but also use it). Till now the only way to add Scala compiler dependencies was a toolchain. If I left the compiler extension as a toolchain dependency there, I could not build the compiler extension due to a cycle in deps (building the compiler extension would depend on itself through the toolchain). I'd like to work this around by defining my own scalac java_binary target, where I can define my own dependencies (and then create rule names with macros that override the scalac target). To do this without duplicating code from rules_scala, refactor SCALAC_DEPS parameter and scalac target definitions to a Starlark file to make them reusable for outside users. Added: - define_scalac() - define_scalac_bootstrap() A user could do: ``` EXTENDED_SCALAC_DEPS = DEFAULT_SCALAC_DEPS + [ "@//my/compiler/dependency:library", ] define_scalac( name = "scalac_with_extensions", deps = EXTENDED_SCALAC_DEPS, ) ``` And then build that compiler library in the same monorepo, this way, providing compiler dependencies without toolchains (that would cause cycles for this usecase). See bazelbuild#1674 for more information.
I'd like to remove Scala compiler extensions from the Scala toolchain, that I could be potentially building myself (in the same monorepo, build the compiler extension, but also use it). Till now the only way to add Scala compiler dependencies was a toolchain. If I left the compiler extension as a toolchain dependency there, I could not build the compiler extension due to a cycle in deps (building the compiler extension would depend on itself through the toolchain). I'd like to work this around by defining my own scalac java_binary target, where I can define my own dependencies (and then create rule names with macros that override the scalac target). To do this without duplicating code from rules_scala, refactor SCALAC_DEPS parameter and scalac target definitions to a Starlark file to make them reusable for outside users. Added: - define_scalac() - define_scalac_bootstrap() A user could do: ``` EXTENDED_SCALAC_DEPS = DEFAULT_SCALAC_DEPS + [ "@//my/compiler/dependency:library", ] define_scalac( name = "scalac_with_extensions", deps = EXTENDED_SCALAC_DEPS, ) ``` And then build that compiler library in the same monorepo, this way, providing compiler dependencies without toolchains (that would cause cycles for this usecase). See bazelbuild#1674 for more information.
I'd like to remove Scala compiler extensions from the Scala toolchain, that I could be potentially building myself (in the same monorepo, build the compiler extension, but also use it). Till now the only way to add Scala compiler dependencies was a toolchain. If I left the compiler extension as a toolchain dependency there, I could not build the compiler extension due to a cycle in deps (building the compiler extension would depend on itself through the toolchain). I'd like to work this around by defining my own scalac java_binary target, where I can define my own dependencies (and then create rule names with macros that override the scalac target). To do this without duplicating code from rules_scala, refactor SCALAC_DEPS parameter and scalac target definitions to a Starlark file to make them reusable for outside users. Added: - define_scalac() - define_scalac_bootstrap() A user could do: ``` EXTENDED_SCALAC_DEPS = DEFAULT_SCALAC_DEPS + [ "@//my/compiler/dependency:library", ] define_scalac( name = "scalac_with_extensions", deps = EXTENDED_SCALAC_DEPS, ) ``` And then build that compiler library in the same monorepo, this way, providing compiler dependencies without toolchains (that would cause cycles for this usecase). See bazelbuild#1674 for more information.
In rules_scala's scalac BUILD file, we have the following.
"//scala/private/toolchain_deps:scala_compile_classpath" is the critical part in my perspective. It's a:
That is in turn a:
Where:
So it comes out that the scala toolchain is the only way to add custom dependencies for the scalac runner.
I guess I can have just a single Scala toolchain active at a time. I'd like to compile two types of targets:
For nr. 1 I need a toolchain that does NOT include the compiler extension (to build the compiler extension).
For nr. 2. I need a toolchain that does include the compiler extension.
The two requirements are mutually exclusive, as I understand, in rules_scala's current implementation.
Is that correct? And is there any way to extend rules_scala, to create another mechanism to provide additional (optional) dependencies for the scalac java_binary, that would be used just for some of the compiled targets?
The text was updated successfully, but these errors were encountered: