Skip to content
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

Cross-compile for Native #700

Merged
merged 5 commits into from
Jul 20, 2022
Merged

Conversation

armanbilge
Copy link
Contributor

Opening PR for fun, after a discussion with @keynmol in the #tooling channel on Discord.

However, this basically required no changes and at least the core tests are passing. Maybe some interesting tooling could be built on this.

@armanbilge
Copy link
Contributor Author

Via #560 (comment) it seems like there could be interest in such a thing!

A few weeks ago I wanted to build a little CLI for myself, and see if I could native-image compile it for speedy runs. So I have an interest in this being becoming available.

@sideeffffect

This comment was marked as outdated.

@armanbilge
Copy link
Contributor Author

Darn, the munit 1.0.0 API changed which is why we're getting compile errors.

@sideeffffect
Copy link

sideeffffect commented May 19, 2022

We seem to be suffering from scala-native/scala-native#2611

[error] Not found Top(java.lang.constant.Constable)
[error] 	at /home/runner/work/mima/mima/core/src/main/scala/com/typesafe/tools/mima/core/ProblemFilters.scala:8

Maybe adding more explicit type annotations could help. But I had to work around the issue by not running Scala 3 Native build on Java >= 12

@SethTisue
Copy link
Collaborator

I just noticed this PR had been sitting, and I hit "approve" on the CI runs.

@armanbilge
Copy link
Contributor Author

Thanks Seth, looks green :)

@SethTisue SethTisue requested a review from dwijnand July 19, 2022 03:10
@dwijnand
Copy link
Collaborator

What are the publication implications of adding cross-compilation for native? The diff looks great (thank you for that!) but I wondered what else it changes for releases.

@@ -37,14 +37,14 @@ val root = project.in(file(".")).settings(
mimaFailOnNoPrevious := false,
publish / skip := true,
)
aggregateProjects(core, sbtplugin, functionalTests)
aggregateProjects(core.jvm, core.native, sbtplugin, functionalTests)
Copy link
Contributor Author

@armanbilge armanbilge Jul 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dwijnand this is the new native sub-project. It's essentially the same if you added a new (JVM) module. So release should work the same.

Does that answer your question?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it's a just another jar submitted to Sonatype? And there are no local system requirements? Compilers, libraries, binaries on PATH, etc? No platform, i.e. Mac/Linux/Windows, implications? I'm not thinking about corner cases and bugs, just regular "what adding Scala Native means to library releases" questions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yup, it's just another Jar :) it's filled with "NIR" (native intermediate representation) files that downstream projects can use to build native binaries. But there's nothing platform-specific we need to do here—we're not shipping a binary.

@dwijnand dwijnand merged commit 52362e7 into lightbend-labs:main Jul 20, 2022
@SethTisue SethTisue added this to the 1.1.1 milestone Sep 16, 2022
@SethTisue
Copy link
Collaborator

#721 makes the necessary tweaks to the release steps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants