-
Notifications
You must be signed in to change notification settings - Fork 54
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
Interest in connecting with https://github.com/nafg/scalac-options ? #39
Comments
This is really interesting @nafg as it presents the possibility of supporting all kinds of patch versions of Scala and prevents us from being able to pass incorrect options! I will look into how this might fit into the plugin. |
Hi, any update? |
Thanks for this ticket @nafg but in the end I went for something a bit coarser-grained in 0.2.0 in ScalacOptions. |
But don't you think there would be any benefit to combining forces somehow? |
Hi @nafg sorry for the long delay but this has just popped into my head again! @satorg, @armanbilge and I have been investigating extracting sbt-tpolecat's logic into a library, and this reminded me of your efforts to generate a DSL for scalac-options. @satorg has been working on some ideas in typelevel/scalac-options#18 and I wondered if you have some thoughts too? |
My thoughts are that the high level API can sit on top of the auto-generated low-level code |
Would you (or anyone) like to have a voice or video chat? |
I wrote a thing that generates an API for scalac options by parsing the output of
scalac -help
etc.: https://github.com/nafg/scalac-optionsWould there be any benefit, or is there any interest, in joining forces somehow?
The text was updated successfully, but these errors were encountered: