Redline maven plugin - #131
Conversation
b659f62 to
7b5388f
Compare
|
on hold, not having jffi requires too much Java versions contorsionism. |
Architecture: - Bridge module uses exec:java with Generator.main() instead of the Maven plugin, breaking the circular dependency (plugin → redline → bridge → plugin) - New redline/build-time-compiler module with RedlineGenerator that handles native code generation and extends generated sources with builder()/safeBuilder()/loadNativeCode() methods - Maven plugin calls RedlineGenerator when <redlineTargets> is configured Config extended with: - redlineTargets: list of target triples for cross-compilation - targetResourceFolder: where .native files are written Generated module class gains (when redlineTargets configured): - loadNativeCode(): loads platform-specific native code from resources - builder(): automatic backend selection (native if platform + Java 25 supported, bytecode otherwise) - safeBuilder(): always uses bytecode compiler NativeMachineFactory.Builder gains toInstanceBuilder() to return a configured Instance.Builder for the generated builder() method. RedlineTarget gains fromTriple() for target triple lookup.
- Add <redline>true</redline> shortcut to compile for all supported platforms (instead of listing 6 target triples) - Add redline/it module with Maven Invoker integration test: - Compiles add.wat.wasm with native code for all platforms - Tests builder() (native), safeBuilder() (bytecode), loadNativeCode() - Verifies native and bytecode produce identical results - Add logging when redline native compilation runs
7b5388f to
66ffb2e
Compare
- Add Rust toolchain + cranelift_bridge.wasm build to ci.yaml - Remove -Predline from release.yaml and redline.yaml - Plugin depends directly on redline-build-time-compiler (no reflection) - Bridge uses exec:java with GeneratorMain to break the cycle - Generated code uses NativeMachineFactoryProvider SPI (no Panama import) - Remove redundant targetResourceFolder from Config - Validate target triples before compilation in RedlineGenerator - E2E tests: JFFI (all JDKs) + Panama (JDK 25+ only) - Restore javadoc comments on Mojo fields
401e2a6 to
f58545f
Compare
| } | ||
|
|
||
| @Test | ||
| public void nativeCodeIsAvailable() { |
There was a problem hiding this comment.
this is machine dependent
| "var host = RedlineTarget.detectHost().orElse(null);")); | ||
|
|
||
| initBody.addStatement( | ||
| StaticJavaParser.parseStatement( |
There was a problem hiding this comment.
no parseStatement + string interpolation, we should use plain JavaParser to build the desired code, is more maintainable in the longer run
| <dependencies> | ||
| <dependency> | ||
| <groupId>com.github.javaparser</groupId> | ||
| <artifactId>javaparser-core</artifactId> |
There was a problem hiding this comment.
javaparser as a dependency of the build time compiler looks a little strange, but maybe worth if it keeps complexity low.
| </dependency> | ||
| <dependency> | ||
| <groupId>run.endive</groupId> | ||
| <artifactId>runtime</artifactId> |
There was a problem hiding this comment.
isn't runtime a transitive dependency of redline?
| <dependencies> | ||
| <dependency> | ||
| <groupId>run.endive</groupId> | ||
| <artifactId>redline-api-experimental</artifactId> |
There was a problem hiding this comment.
do we need to explicitly add the api module? isn't it transitive from runner?
| <configuration> | ||
| <name>endive.test.AddModule</name> | ||
| <wasmFile>src/test/resources/add.wat.wasm</wasmFile> | ||
| <interpreterFallback>WARN</interpreterFallback> |
| } | ||
|
|
||
| @Test | ||
| public void nativeCodeIsAvailable() { |
There was a problem hiding this comment.
this is machine dependent
| <version>0.0-SNAPSHOT</version> | ||
| <packaging>jar</packaging> | ||
|
|
||
| <dependencies> |
There was a problem hiding this comment.
same comments as above for the transitive deps
Replace Rust toolchain + make all in CI with inlay-maven-plugin fetching the pre-built wasm from ghcr.io/bytecodealliance/endive-cranelift-bridge. No Rust needed in any CI workflow except the new wasm-publish.yaml. - Bridge POM: inlay:fetch before exec:java GeneratorMain - Root POM: add inlay-maven-plugin to pluginManagement - CI/redline/release workflows: remove Rust toolchain steps - New wasm-publish.yaml: build + publish wasm to GHCR on wasm-build changes - wkg.lock: pins wasm digest for reproducible builds
No description provided.