-
Notifications
You must be signed in to change notification settings - Fork 129
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
Add resources support to Scala Native and fixes to overall resources #812
Conversation
78f2480
to
dd0d7f0
Compare
9d7f503
to
9cfe915
Compare
I have heavily updated the PR message to reflect the new scope of the PR (now with fixes for the java resources outside of SN) |
9cfe915
to
503b2d2
Compare
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 see you just pushed things. Here's my in progress review comments.
modules/cli-options/src/main/scala/scala/cli/commands/ScalaNativeOptions.scala
Outdated
Show resolved
Hide resolved
modules/cli-options/src/main/scala/scala/cli/commands/ScalaNativeOptions.scala
Outdated
Show resolved
Hide resolved
modules/cli-options/src/main/scala/scala/cli/commands/ScalaNativeOptions.scala
Outdated
Show resolved
Hide resolved
Sorry about sudden pushing, I did it to (hopefully) fix the issues with the failing gif tests in the CI, the committed code was not changed, only rebased |
...ain/scala/scala/build/preprocessing/directives/UsingScalaNativeOptionsDirectiveHandler.scala
Show resolved
Hide resolved
modules/integration/src/test/scala/scala/cli/integration/RunTestDefinitions.scala
Show resolved
Hide resolved
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.
About the resource mapping stuff: do we really need to write an actual mapping file on disk like this? Couldn't we instead write a list of relative paths of the resources written in the output dir, and right before copying / updating resources, look at those that will not be overwritten, and remove them?
The resource safety thing (ensuring we remove stale resources) is really great, but maybe it could be done in a separate PR?
80e04e6
to
d7d1da0
Compare
e0a89c5
to
4c7e369
Compare
I have updated the mapping file contents to store only the relative output paths, as was suggested. I am not sure about the gains splitting the PR would give us (outside of easier review), since both the SN improvements and fixes to overall fixes to resources depend on the mapping mechanizm - I imagine if something goes wrong we would still have to revert both. |
4c7e369
to
20382a7
Compare
337caf5
to
770a0d3
Compare
I reworked a bit the commit history, to make it easier to review this. I'll have a closer look a bit later. |
This comment was marked as outdated.
This comment was marked as outdated.
770a0d3
to
14f795f
Compare
So I rebased on the latest |
14f795f
to
ef1f76a
Compare
This comment was marked as outdated.
This comment was marked as outdated.
ef1f76a
to
48e9bcc
Compare
Previously this would have no effect on the program. With this commit a mapping feature was introduced to resources, which remembers from where a resource file originates. An integration test for the issue was also added.
Works automatically when a resourceDir option or using Directory is added. Having that working effectively required fixing duplicated classpath in Scala Native packaging. Will work only on Scala Native 0.4.4 and up. Caching was also improved, as previously only the cli option resources would be cached, and using directive resources would be ignored. A --embed-resources option was also added, allowing to disable resource embedding (which will also make the resources API not work). The use case for this is using c interop without having unnecessary libraries metadata embedded, taking up space in a binary file.
This should provide simpler interop functionality, removing to rely on passing c files through resource directories. A new resource caching mechanizm was also added, to smoothen the development experience. Before, it would be easy for SN linking errors to appear - any rename or move of an interop file would cause it to be duplicated. The mappingremoves those issues, as long as users will not tamper with the newly added file (.project_native_resources) to output directory. This can be extended for use with regular JVM resources, to solve a similar issue.
48e9bcc
to
6f25287
Compare
This PR allows to embed resources (by default) in a SN binary, as well as fixes some bugs that ended up being related. Those can be then accessed via getResourceAsStream Java API. An integration test was also added.
While working on this I ended up fixing a couple bugs that did not have a chance to show until now, connected with scala-cli SN support:
I later got some feedback and decided to also allow using c files as regular inputs, instead of using them via resources (which is basically how the underlying Scala Native handles them). This required me to make a very simple fix of #808 (and #1209), which I did for both the newly added C files, and regular java-style resources.
We now store in .scala-build an additional file which stores mapping between the path of the original c file/resource and the one copied internally for building. This way we can delete the internal files in case it disappears in the original path, which eliminates files doubling when renamed etc.
In summary:
.scala-build
and the classpath #808 and Not recognizing removed resources #1209