-
Notifications
You must be signed in to change notification settings - Fork 73
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
Support Scala Native #340
Support Scala Native #340
Conversation
Thanks for this. I'm not sure whether any of the other Jawn maintainers use Scala Native, and I'm a little worried about adding build complexity in a key project. At the same time, without doing so, we can't begin to support downstream projects in Scala Native. It doesn't complicate the code. I'm willing to give it a shot, as long as we get help if it breaks or can throw it overboard if it blocks the JVM use case. |
@rossabaker Thank you! |
Sounds good to me. Let's try it. Looks like we broke the Scala 3 build somehow. I'm confused, because it says it's the JVM project, but I see native things happening. |
Something was going on with making available the dummy |
I made a silly mistake which made all the tests be skipped on Scala Native. The scalacheck dependency needs the |
No worries. I approved the CI run, to see if it uncovers any more surprises. |
Claimant 0.2.0 on its way to Maven Central. |
After giving it a bit of thought I'm going to deprecate Claimant (typelevel/claimant#110). We should remove the dependency here. |
Would we then port this to expecty, or just drop the fancy assertions? |
I vote drop fancy assertions. Jawn is stable; for all I care the tests just say "yes" or "no" 😉 |
#348 is merged so we don't need the claimant stuff anymore |
66c836f
to
978c9ba
Compare
I rebased the branch on top of the current I can, alternatively, put them in a Let me know. |
978c9ba
to
1cf85a8
Compare
lazy val jawnSettingsNative = Seq( | ||
crossScalaVersions := crossScalaVersions.value.filterNot(ScalaArtifacts.isScala3) | ||
) |
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.
How does this interact with the ++3.0.0
used in CI?
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.
It seems to me that runs only the tests in JVM and JS projects since the native project doesn't have that version.
If you run:
> ++3.0.0
> astNative/test
It runs the 2.12 tests instead.
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.
Hmm. It's probably fine for tests, but what happens with +publish
. Does it try to publish 2.12 artifacts for native twice?
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 tried +publishLocal
and it seems fine actually. Go figure?
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.
Yeah, I wasn't able to reproduce the problems that a platform with less scala versions create..
@rossabaker Can you approve the CI run again? |
@rossabaker Thanks for the approval! Sorry to disturb you again :/ |
No worries. Bummer we're on different time zones. 😄 |
CI is green now 🥳 |
@rossabaker Can this be merged now? :) |
@lolgab your goal is to use this to cross circe for native, correct? Or do you see stand-alone uses? |
@armanbilge |
Do you know if Circe is open to a native cross rn? I guess it would depend on the build complexity, but lately seems to be trying to reduce the crosses: circe/circe#1818 It should be possible to cross Circe core without this, I think, to test the waters there maybe :) |
@armanbilge You're right, I need to ask there first. |
The We all love Jawn but it's wholly possible that plugging |
Btw, I'm generally for this, esp. since Jawn is needed for http4s-native (watch out Ross!) regardless of what circe uses for native parsing ... but we are still quite a ways off from that. |
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 know anything about scala-native, but it looks like this passes without unduly complicating the other builds. What is the compatibility story? When scala-native-0.5 is released, will another jawn release be required? Would it be okay to handle that in a minor jawn bump?
Like I said in the spring, I want to support this without putting the predominant platform at any extra risk, but it looks like you've accomplished it!
The artifact suffix will change (see how cats-native is published: https://repo1.maven.org/maven2/org/typelevel/cats-core_native0.4_2.12/) so wouldn't need anything special with jawn versioning: introduce a new cross-build for it (and most likely drop the old one). |
Okay, we have two people on this thread who know what they're doing. We'll keep it if you can keep it running or recruit more people who can. 😄 |
Blocked by:
FileInputStream#getChanneljava.io.FileInputStream#getChannel
is not implemented scala-native/scala-native#2303Claimant on Scala Native Support Scala Native claimant#132