Job for native file system compilation artifacts? #2780
Replies: 2 comments 7 replies
-
That's indeed a pain-point, but setting up a fully working native compilation pipeline would require quite some changes, including moving the Jenkins jobs of this project from the It's all doable as SWT and Equinox prove. However, since Java-25 is allowed for the next development cycle, i.e. for the December release, the JNA and native code based file-system implementations are the first parts I want to use FFM for. Since I think it's not worth the effort to set up such native compilation for two, three months, my suggestion is to either hold back the contribution you linked until September (where the new cycle starts) or use a multi-release jar in the meantime. |
Beta Was this translation helpful? Give feedback.
-
|
OK, thanks everyone. I decided to not invest time in MR story, and simply provide a Linux binary which I can build/test/debug/validate, see #2793 :-) If in 4.42 we would be able to use Java 25 for platform, we should be able to port the code to FFM and get rid of native binaries. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Triggered by #2779, I see that our file system native bits (
org.eclipse.core.filesystem.*) are manually checked into git and not automatically generated / checked in like in SWT.I wonder if we can update our build pipeline to build native artifacts "on the fly"?
The reason for doing so is: with #2779 I must provide native bits for Mac too, but I have no access to Mac at all. If we would have automated artifacts build & check in, the problem could be solved.
Another alternative for me now is to split Mac & Linux implementations and make sure the PR only affects Linux code or somehow cross-compile on Linux for Mac (no idea how).
Any thoughts?
Beta Was this translation helpful? Give feedback.
All reactions