Interest in connecting with https://github.com/nafg/scalac-options ? about sbt-tpolecat HOT 8 CLOSED

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.

from sbt-tpolecat.

Hi, any update?

from sbt-tpolecat.

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

from sbt-tpolecat.

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!

from sbt-tpolecat.

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

from sbt-tpolecat.

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?

from sbt-tpolecat.

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

from sbt-tpolecat.

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

from sbt-tpolecat.