Build logic renovation?

[John Neffenger]

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