Hi! I think your patches are a bit difficult to review. I'll have a proper look this evening, but for now two things I noticed: You declare configure flags as a list of flags, but at some point you have: "-DCMAKE_CXX_FLAGS=\"" … "\"" In the list. I think it's incorrect because they would be passed as separate arguments (though it might work when parsed by the program). I think you should zake it a single argument with string-append. Also, we should now use the new style inputs for packages when possible: (list foo bar) instead of `(("foo" ,foo) ("bar" ,bar)) Thanks! On June 19, 2022 9:26:32 PM GMT+02:00, Ioannis Kappas wrote: >Hi, > >could you please consider reviewing patches to finalize the building >of the java-openjfx packages in scope of this discussion, as part of >an attempt to complete Alexey's awesome work. > >The thread had stopped receiving updates for some time now. I assume >priorities were shifted elsewhere. > >I recently got interested testing an openjfx application on Java 1.8, >only to realise that the current packages are incomplete. I came >across this thread, and thought to give the patches a try, and fix >where possible. > >I believe I have finalised all openjfx packages in scope to build, >pass all tests and seamlessly link to their native libraries at >runtime. > >My test application now works, I can use the graphics, controls and >web openjfx packages by merely specifying their share/java jar >packages on the classpath. > >This email has three incremental patches. I've named the as [PATCH v5] >to denote this is a continuation from the last patches. > >0001: Alexey's work brought forward to a recent guix revision. > >0002: Small changes to updated the above to build with the current >guix spec/packages. > >0003: My update to finalize the openjfx packages, normalize inputs, >run all tests where they exist and fix the load path of native >libraries at runtime. > >I've put the author of 0001 down to Alexey since this is his works. I >compiled this patch by hand from the thread, I hope I haven't missed >anything. > >The individual packages produce a jar output, and some of them also >build native shared libraries. The individual jar packages try to load >their native libraries just by name, and this will fail if the native >libs are not on the library path. > >I've taken the decision to load these libraries by their full >gnu/store path instead of their names. I have also applied the same to >an external package, java-swt, since it has a shared library that has >to be located at runtime. Although there are a few native libraries >built by the java-openjfx-graphics package I left it as is, because it >has a sophisticated native library loader that locates shared >libraries relative to the jar location. > >The changes in 0003 are as follows: > >* java-openjfx-graphics > 1. Normalize inputs, only build against gtk-2.0. > 2. Output native libs to openjfx standard share/amd64 dir. > 3. Do not build libjpeg from source, but rather use corresponding > package. > 4. Run all tests. >* java-openjfx-controls > 1. Run all tests. > 2. Fix java-openjfx-graphics name typo. >* java-openjfx-media > 1. Build against gstreamer. > 2. Compile native library and modify loader to load it directly from > the store path. >* java-openjfx-web > 1. Include version. > 2. Modify loader to load native web kit lib directly from the store. > 3. Fix a failing test, by applying new > java-openjfx-build-web-js-test.patch as picked up from a later > openjfx revision source code revision, to fix a failing test. > 4. Run all tests. >* java-swt > 1. Modify loader to load native library directly from the gnu/store > path if it can't be found otherwise. This is required for > seamlessly loading java-swt as an input. > >This is my first guix package update, so is likely to require more >work based on your feedback, which is most welcome. > >Thanks