Interest in connecting with https://github.com/nafg/scalac-options ?

[nafg]

I wrote a thing that generates an API for scalac options by parsing the output of scalac -help etc.: https://github.com/nafg/scalac-options

Would there be any benefit, or is there any interest, in joining forces somehow?

[DavidGregory084]

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.

[nafg]

Hi, any update?

[DavidGregory084]

Sorry @nafg I have been swamped on UK transit projects for ~18 months and I am just starting to emerge from the wreckage 😆

I've started a more detailed discussion about this in #49

[DavidGregory084]

Thanks for this ticket @nafg but in the end I went for something a bit coarser-grained in 0.2.0 in ScalacOptions.
The reason is that the way that sbt-tpolecat works is slightly different to the API offered by scalac-options - the user selects all of the options that they want to enable without having to think about which Scala version they are using, and sbt-tpolecat does its best to filter out the ones that will work for their Scala compiler version, whereas scalac-options kind of requires the user to understand which options are available in each version. Hopefully that makes sense!

[nafg]

But don't you think there would be any benefit to combining forces somehow?

[DavidGregory084]

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?

[nafg]

My thoughts are that the high level API can sit on top of the auto-generated low-level code

[nafg]

Would you (or anyone) like to have a voice or video chat?