-
-
Notifications
You must be signed in to change notification settings - Fork 287
Simplify setup of scala_toolchain and its deps #1439
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
Simplify setup of scala_toolchain and its deps #1439
Conversation
| scala_library_classpath_provider = "%s_scala_library_classpath_provider" % name | ||
| scala_macro_classpath_provider = "%s_scala_macro_classpath_provider" % name | ||
|
|
||
| print("XML", scala_xml_provider) |
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.
Is this really needed?
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, for catching, @simuons!
|
|
||
| def setup_scala_toolchain( | ||
| name, | ||
| scala_xml_deps, |
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.
nit: why some attribute names ends with deps and others with classpath? What's the distinction?
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.
classpath is what historically was used on the toolchain, other names came when dep providers were introduced. How I see it: classpath is implicit deps on the classpath, and deps is tool related deps. But this naming assumption does not even hold with the current codebase (eg. compiler is tool, but has classpath naming). Not sure what to do about it. It's a good time to improve those names at least on the macro side. Naming suggestions are more than welcome. @simuons, WDYT?
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 don't really have good suggestion. I wasn't aware of this distinction about classpath and tools. My initial thought was "all those deps go to the classpath at some point so why the distinction". The question probably is wether users should set 'internal' deps for things like //scala/support:test_reporter but this is out of scope for this PR. So I'm ok with state as it is now.
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.
After thinking a bit more, I'll change it to use default providers for tools deps. This should give us more room to do future refactorings. Eg. move scala_xml dep to testing toolchain.
|
@simuons I have made scala xml and parser combinators deps to be default if not specified |
fd8d753 to
6b522fc
Compare
Description
Added
setup_scala_toolchainmacro to simplify scala toolchain setup.Motivation
To configuration of custom scala toolchain one needs to understand implementation details like dependency provider ids, which makes it a complicated task. We can encapsulate those details under a macro.