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 <ioannis.kappas@gmail.com> 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