I am with John that the direction we should invest in is the path Johan
suggested, and give it our best shot.
A build system isn't just "done once". It is a continual maintenance task.
And if we can largely leverage the work done for JDK it will mean
savings all round, now and in the future.
-phil.
On 5/27/25 12:27 PM, John Neffenger wrote:
Hi, Jesper. My comments below are not meant to discourage you entirely
from your plans -- really! :-) -- but rather to help you understand,
based on my own experience, the scope of the work involved.
On 5/27/25 6:41 AM, Jesper Skov wrote:
Would there be interest in reworking the build logic?
Yes, but perhaps more like this:
Building OpenJFX using JDK
https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/
All the procedural Gradle in one large file makes it hard to
understand the build logic.
Indeed.
It looks very complex.
It is very complex.
And it may be performing below optimum (this is just a conjecture).
Without a doubt.
I know that the current build is very obviously working.
Barely. :-)
And that there may good reasons to keep it in its current form.
No, not really, except for the "very obviously working" part.
But if there is an interest, I would like to make the build more
idiomatic Gradle.
Personally, I'm done with Gradle for any of my own projects. It's
difficult to pin down precisely the way in which Gradle fails to be a
good build system, but I think Bruce Eckel summarized it best in his
article below:
Jan 2, 2021 - 16 minute read
The Problem with Gradle
https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/
Changing the build would be an explorative and iterative task.
The JavaFX build system is remarkably complicated. It is based on
Gradle but also uses other build tools such as Apache Maven, Apache
Ant, GNU Make, CMake, Ninja, GNU GCC, Apple Xcode, Microsoft Visual
Studio, and even Windows batch files. It runs on Linux, macOS, and
Windows, and supports eight different hardware architectures (last
time I counted).
Testing requires you to configure and run hundreds (!) of these complex
builds and unit tests on multiple systems under Linux, macOS, and
Windows.
I'm tempted to say that having (almost) reproducible builds in JavaFX
would help in verifying that you're creating the same artifacts before
and after, but there are just so many artifacts to verify. It's not
one build that produces a set of artifacts. Rather, it's multiple
builds that produce multiple sets of artifacts on multiple systems.
And I would need to know if there are some non-obvious out-of-tree
features that need special handling.
Almost everything in it needs special handling.
I can understand if you would be wary about this proposal; I may not
be able to complete the transition from the current to a new build.
I think you're looking at a multi-year project.
John
