Conversation
This path avoids the sources getting wiped out during `mvn clean`, since they are not generated during the maven build. This patch also moves the generated WASM build under src/main/wasm since it is really a source file and not a test file. It will not be included in the built artifact.
|
The archive of the sources generated specifically for TruffleRuby could be moved to a separate job if that would be cleaner. |
|
Could Loader.java and Nodes.java simply be in |
| jar --create --file java/prism-truffleruby-sources.jar -C java/api/src/main/java `ls -r java/api/src/main/java` | ||
| jar --update --file java/prism-truffleruby-sources.jar -C java/api/src/main/java-templates `ls -r java/api/src/main/java-templates` | ||
| jar --update --file java/prism-truffleruby-sources.jar -C java/native/src/main/java `ls -r java/native/src/main/java` |
There was a problem hiding this comment.
I appreciate the thought and effort but it's better to directly copy files from my Prism checkout, that way it also works if e.g. I have some local changes in Prism I'm testing in TruffleRuby.
So this can be removed.
| package org.ruby_lang.prism; | ||
| package org.ruby_lang.prism.jni; | ||
|
|
||
| public abstract class Parser { |
There was a problem hiding this comment.
This class, which is the only class under java/native doesn't really do anything currently.
Notably the corresponding C code is not here, it's in https://github.com/truffleruby/truffleruby/blob/master/src/main/c/yarp_bindings/src/yarp_bindings.c.
Maybe we should actually remove this class? Or import the C file here?
If the C file would get compiled in CI that could be nice, as it'd catch cases that it needs to be updated, e.g. with the recent changes in the C API.
OTOH this is an area where usages might want different things (e.g. how the reading is done, maybe from a file/using mmap/etc), and notably truffleruby compiles that .c file together with libprism.a.
I'd tend to say the simplest is to just remove this file, but then maybe there is an issue because java/native is empty?
There was a problem hiding this comment.
The logical change would be to put the JNI C code in here as well and use Maven to build it. But there's the larger issue of building, packaging, and releasing that JNI library.
I have looked briefly at the available Maven tooling for building and releasing native libraries but never attempted to use them:
https://www.mojohaus.org/maven-native/native-maven-plugin/
Unfortunately the source links for this plugin appear to be dead. I'm not sure what is considered "standard" for building and releasing JNI libraries at this point.
There was a problem hiding this comment.
Ah, the link from the mojohouse page was incorrect. The plugins are here:
There was a problem hiding this comment.
Looking into other projects that publish native libraries, I have found no standard tooling to do this.
lwjgl builds and publishes an extensive set of native binaries, but they also have an enormous set of ant build files to do it. MacOS example: https://github.com/LWJGL/lwjgl3/blob/4ef1eebe4af235b2934a165e82aeefcaf8d9b893/config/macos/build.xml#L140
Of course JRuby's JFFI also publishes many native libraries, but we have always built them by hand and committed them to the repository due to the challenges of doing this automatically.
3 participants
Based on review comments from #4031 I've made a few additional tweaks.
src/main/java-templatesso they are not deleted bymvn clean.src/main/wasmsince it is an input to the build (and not a test resource as before).