Build logic renovation?

[Philip Race]

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
>