Closed zakkak closed 1 year ago
However it comes at the cost of the following build-time dependencies:
* ANTLR4 * TRUFFLE_ASM * TRUFFLE_JCODINGS
Unfortunately, dropping these dependencies results in build failures, as expected. As a result IMO it's not worth the effort as it's not a priority for us. @jerboaa WDYT?
Let me try to sound-board this. Right now, we don't support truffle-runtime. If we were to include truffle-runtime, then we'd depend on antlr4
, truffle-asm
, truffle-jcodings
? Did I get this correct?
If I did understand this correctly, then those dependencies are not worth the trouble of \<insert-benefit-here\>. We haven't needed it in the past and packaging those dependencies is a can of worms I'd rather not open.
Is the plan to get this merged?
You got it right.
No the plan is to not merge it. I opened it as draft to have in record what we tried and why we don't want it (at least for now). I am closing it.
Thanks for the clarification.
@zakkak let me know if I can help with the truffle svm runtime integration in Mandrel. Its definitely much easier now to integrate truffle in the new unchained world since 23.1. All you basically need to keep is the truffle-svm-runtime.jar and the truffle-svm macro. You should not add it to the builder class-path always as it has a lot of dependencies we can only resolve if truffle-runtime.jar is on the class or module-path.
The way this works is that if truffle-runtime.jar is on the class or module-path it activates the truffle-svm
macro.
The macro looks like this in a GraalVM JDK:
ImageModulePath = ${.}/../../../truffle/builder/truffle-runtime-svm.jar
Args = -H:CLibraryPath=${.}/builder
IgnoreIfBuilderOnClasspath = true
Customizing this allows you to put the truffle-runtime-svm.jar anywhere you want. You just should not put it on the builder class-path by default as it requires a lot of dependencies regular applications don't have.
@chumer thanks for looking into this.
Our main issue is that in order to build truffle-svm-runtime.jar
we need the following two dependencies that are truffle specific (and thus not in our internal build chain):
If we could use the original ASM and JCODINGS it would allow us to build without issues AFAIU.
@zakkak you should be able to use the 23.1 (or latest LTS) of truffle and its dependencies from Maven central to build truffle-svm-runtime.jar. We are currently considering to move to a build like this internally by default. No decision yet.
you should be able to use the 23.1 (or latest LTS) of truffle and its dependencies from Maven central to build truffle-svm-runtime.jar.
We build everything from source, so an external dependency from Maven central is not possible for us.
@jerboaa you only need it to compile you don't need to ship any of these things.
@chumer Since it's a compile time dependency, we need to build the compile time deps from source too. That's the trouble.
@jerboaa we could use the new mx builtin auto-shader based on the original ASM and JCODINGS dependencies that we already use for ICU4J. Would that work? Feel free to open an issue for us then.
Hi,
are there any plans on making truffle work in native-image with mandrel? I'm getting an error while trying to build a project using it:
Error: Processing jar:file:///home/mkaminski/work/exec-engine/build/exec-engine-0.1.0-SNAPSHOT-native-image-source-jar/lib/org.graalvm.truffle.truffle-api-23.1.1.jar!/META-INF/native-image/org.graalvm.truffle/native-image.properties failed
Caused by: com.oracle.svm.driver.NativeImage$NativeImageError: Unknown name in option specification: macro:truffle-svm
are there any plans on making truffle work in native-image with mandrel?
No, sorry. There are no plans on supporting that. Use GraalVM for JDK 21 instead.
@jerboaa we could use the new mx builtin auto-shader based on the original ASM and JCODINGS dependencies that we already use for ICU4J. Would that work? Feel free to open an issue for us then.
I think that could work, will give it a try.
FTR the referenced code above is https://github.com/oracle/graal/blame/d5f2e7c44a2f9c123d78d0dcffa1c096152d6286/truffle/mx.truffle/suite.py#L1088 (since the original link is not a permanent one)
Disclaimer: This doesn't mean we plan to support Truffle, we are just experimenting at this stage.
This change only increases the Mandrel installation by 1MB, while allowing users to use Truffle maven artifacts.
However it comes at the cost of the following build-time dependencies:
Unfortunately, dropping these dependencies results in build failures, as expected. As a result IMO it's not worth the effort as it's not a priority for us. @jerboaa WDYT?