Scala-native support
francisdb opened this issue · comments
I was looking at using some parts of akka-http but it seems that the underlying akka-parse is embedding parboiled2 and shapeless. Shapeless is available for scala-native so only parboiled2 remains.
This would for now limit parboiled2 to scala 2.11 as scala-native 0.4.x with scala 2.12 support is not yet available. But that should be no problem as the current base platform is 2.10.
Looks like everything compiles without problems on scala native, only the specs2 dependency is an issue.
@xuwei-k I see you already requested scala native upstream etorreborre/specs2#591
Any chance a native release could be pushed without the tests having run?
To be honest, I have moved off specs2 and towards Scalatest or even @lihaoyi's utest on all my newer projects. So, if the specs2 dependency becomes a liability for a potential support of scala-native then I'd support a switch of test infrastructure to sth else.
That shouldn't be hard to do at all since, AFAIK, there is nothing specs2-specific that we really depend on in the tests...
Indeed the fastest path here would be switching testing frameworks, so which test framework would you prefer?
I see there is one test using ScalaCheck, that is not yet released for scala native
I think we should move to https://github.com/lihaoyi/utest.
It does all we need and doesn't get in the way.
And the one test currently relying on ScalaCheck can surely be easily rewritten to a custom generator as well...
I've published the artifact under my groupid having seen no interest about Scala Native by scalacheck maintainer. You can use "com.github.lolgab" %%% "scalacheck" % "0.4.1"
as Scala Native dependency on other libraries.
Let's see if I can get these tests ported to utest
looks like the utest-scalacheck example at com-lihaoyi/utest#2 might allow to keep the scalacheck part (using @lolgab 's release)
@sirthias should I start from the release-2.1
branch?
@francisdb Yes, the release-2.1
branch really should be the master...
The master is essentially a failed (due to capacity restriction on my side) attempt to pull the library to the next level.
@sirthias the parboiled -
macro seems to conflict with the parboiled -
macro, any hints on how I can workaround that?
(I have a not so pretty workaround, will keep a TODO comment in the PR)
Sorry, @francisdb, I don't understand you question...
@sirthias I understand you don't understand, you will see what I mean once the PR is ready