Re: Building OpenJFX.

[Kevin Rushforth]

So making gradlew optional seems best then, if added.

-- Kevin


Mario Torre wrote:

2017-12-19 23:04 GMT+01:00 Scott Palmer :
  

The project should be configured to use the Gradle Wrapper, so the correct 
version of Gradle is used automatically.



This is not an option for Linux distributions and is not an option for
many people using them. We need to be able to produce a build with an
all local toolchain.

Cheers,
Mario
  

Re: Building OpenJFX.

[Tom Schindl]

Hi Phil,

As I've went through the (painful) process of getting OpenJFX build on 
Windows (without the Webkit part) for a Build-Dummy like myself I've 
documented those steps 1 by 1 - 
https://github.com/BestSolution-at/openjfx-build/blob/master/README.md


Tom

Am 2017-12-19 21:11, schrieb Phil Race:

In the "innovation" email thread it was suggested that one obstacle to
getting involved and contributing to OpenJFX is just building it.

So what are the top one or two pain points with building OpenJFX today 
?


- Insufficient or out-dated build docs ?
- Tool-chain configuration problems - platform-specific or otherwise ?
- Needing to do a JDK build as well (JDK 9 and later) ?
- Something else ?

And having identified your pain point(s), what do you think would be a
solution ?

-phil.

Re: Building OpenJFX.

[Kevin Rushforth]

Yes, if I do nothing else before Christmas I will update the 
per-platform instructions for the three platforms (especially Windows) 
to be current. For Windows, the current compiler is VS 2017.


-- Kevin


Chris Newland wrote:

Hi Phil,

Would it be possible to update the Windows build instructions? Getting
VS10 and SDKs from 2010 to work on a Windows 10 build machine isn't much
fun.

Thanks,

Chris



On Tue, December 19, 2017 20:11, Phil Race wrote:
  

In the "innovation" email thread it was suggested that one obstacle to
getting involved and contributing to OpenJFX is just building it.

So what are the top one or two pain points with building OpenJFX today ?


- Insufficient or out-dated build docs ?
- Tool-chain configuration problems - platform-specific or otherwise ?
- Needing to do a JDK build as well (JDK 9 and later) ?
- Something else ?


And having identified your pain point(s), what do you think would be a
solution ?

-phil.






  

Re: Building OpenJFX.

[Scott Palmer]

> On Dec 19, 2017, at 5:13 PM, Mario Torre  
> wrote:
> 
> 2017-12-19 23:04 GMT+01:00 Scott Palmer :
>> The project should be configured to use the Gradle Wrapper, so the correct 
>> version of Gradle is used automatically.
> 
> This is not an option for Linux distributions and is not an option for
> many people using them. We need to be able to produce a build with an
> all local toolchain.

The availability of the Gradle Wrapper does not mean you have to use it though. 
 It would be helpful for those that can use it, at least if they suspected a 
Gradle incompatibility to be contributing to their builds problems.  I have 
found that most Gradle versions since 3.x have worked fine on my projects 
without requiring any tweaks.

Regards,

Scott

Re: Building OpenJFX.

[Kevin Rushforth]

While I doubt such issues are “real” I understand that you have to deal with 
Oracle lawyers.


It might be worth asking again to see whether there are any concerns. If 
we can address them, then maybe this is the way to go.



Perhaps a solution then is to configure the wrapper via a setup step to run the 
wrapper task with any version of gradle that can handle it, then run the 
gradlew script that it generates.


And if not, then this is good alternative.


What I would really like to see, and I know I’m asking for a lot, is the 
elimination of the Cygwin requirement and the use of the Gradle native plugin 
for the native code (maybe we can exclude WebKit from that for now)
You shouldn’t need Ant either.
  


Yeah, that would be a big task, but possibly worth someone looking into 
(as for myself, I consider Windows to be unusable without Cygwin as a 
developer, so it wouldn't occur to me to want to build on a system 
without it). Eliminating the need for ant would require some work to 
refactor the apps, but is conceptually easy.



It should be easy to build without WebKit and have pre-built WebKit binaries 
pulled in like any other dependency instead, based on a build property. E.g. 
gradlew -PusePrebuiltWebKit=true
  


We already have a mechanism to point to a (possibly early access) JDK to 
grab the binary from there (see the STUB_RUNTIME variable). It wouldn't 
be too hard to extend that.


Thanks for the suggestions.

-- Kevin



Scott Palmer wrote:

The project should be configured to use the Gradle Wrapper, so the correct 
version of Gradle is used automatically.
https://docs.gradle.org/current/userguide/gradle_wrapper.html 


There was some concern about checking in the gradle-wrapper.jar file, and 
potential licensing issues.  While I doubt such issues are “real” I understand 
that you have to deal with Oracle lawyers.  Perhaps a solution then is to 
configure the wrapper via a setup step to run the wrapper task with any version 
of gradle that can handle it, then run the gradlew script that it generates.

e.g.
build.gradle contains:
task wrapper(type: Wrapper) {
  gradleVersion = '4.3'
}

one-time setup:
gradle wrapper

run the build:
gradlew

Gradle bumps should be able to happen any time without causing issues.  Gradle 
becomes just another dependency that is automatically fetched. A simple check 
to make sure the Gradle version is okay can be coded into the build script, 
e.g. something like:

def blessed_gradle_version = '4.3'
task wrapper(type: Wrapper) {
  gradleVersion = blessed_gradle_version
}
if (project.gradle.gradleVersion != blessed_gradle_version) {
  println "Build expects ${blessed_gradle_version} but found 
${project.gradle.gradleVersion}\n Run 'gradle wrapper', then use 'gradlew'"
} else {
  apply from: 'real_build.gradle'
}

Gradle incompatibilities should be rare anyway.

What I would really like to see, and I know I’m asking for a lot, is the 
elimination of the Cygwin requirement and the use of the Gradle native plugin 
for the native code (maybe we can exclude WebKit from that for now)
You shouldn’t need Ant either.

It should be easy to build without WebKit and have pre-built WebKit binaries 
pulled in like any other dependency instead, based on a build property. E.g. 
gradlew -PusePrebuiltWebKit=true

Regards,

Scott

  

On Dec 19, 2017, at 4:17 PM, Kevin Rushforth  wrote:

Building WebKit is challenging, to be sure. I hope to enlist the help of some 
of our WebKit team members to review (and contribute to) update build 
instructions to help make it a little less painful, but it is still a challenge.

As for the moving version of gradle, we so far have settled on a specific 
version for each release family: gradle 1.8 for JDK 8u, 3.1 for JDK 9, and 4.3 
for JDK 10. We don't tend to bump it.

Thanks for the feedback.

-- Kevin


Mario Torre wrote:


For me the most intricate part is about building the webkit based
code, especially on RHEL/CentOS. I admit I didn't try with the very
latest code drop though. The moving version of Gradle is also an
issue, since we try to use a stable toolchain on those OSes.

Cheers,
Mario

2017-12-19 21:11 GMT+01:00 Phil Race :
 
  

In the "innovation" email thread it was suggested that one obstacle to
getting involved and contributing to OpenJFX is just building it.

So what are the top one or two pain points with building OpenJFX today ?

- Insufficient or out-dated build docs ?
- Tool-chain configuration problems - platform-specific or otherwise ?
- Needing to do a JDK build as well (JDK 9 and later) ?
- Something else ?

And having identified your pain point(s), what do you think would be a
solution ?

-phil.

Re: Building OpenJFX.

[Chris Newland]

Hi Phil,

Would it be possible to update the Windows build instructions? Getting
VS10 and SDKs from 2010 to work on a Windows 10 build machine isn't much
fun.

Thanks,

Chris



On Tue, December 19, 2017 20:11, Phil Race wrote:
> In the "innovation" email thread it was suggested that one obstacle to
> getting involved and contributing to OpenJFX is just building it.
>
> So what are the top one or two pain points with building OpenJFX today ?
>
>
> - Insufficient or out-dated build docs ?
> - Tool-chain configuration problems - platform-specific or otherwise ?
> - Needing to do a JDK build as well (JDK 9 and later) ?
> - Something else ?
>
>
> And having identified your pain point(s), what do you think would be a
> solution ?
>
> -phil.
>
>

Re: Building OpenJFX.

[Mario Torre]

2017-12-19 23:04 GMT+01:00 Scott Palmer :
> The project should be configured to use the Gradle Wrapper, so the correct 
> version of Gradle is used automatically.

This is not an option for Linux distributions and is not an option for
many people using them. We need to be able to produce a build with an
all local toolchain.

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Building OpenJFX.

[Scott Palmer]

The project should be configured to use the Gradle Wrapper, so the correct 
version of Gradle is used automatically.
https://docs.gradle.org/current/userguide/gradle_wrapper.html 


There was some concern about checking in the gradle-wrapper.jar file, and 
potential licensing issues.  While I doubt such issues are “real” I understand 
that you have to deal with Oracle lawyers.  Perhaps a solution then is to 
configure the wrapper via a setup step to run the wrapper task with any version 
of gradle that can handle it, then run the gradlew script that it generates.

e.g.
build.gradle contains:
task wrapper(type: Wrapper) {
  gradleVersion = '4.3'
}

one-time setup:
gradle wrapper

run the build:
gradlew

Gradle bumps should be able to happen any time without causing issues.  Gradle 
becomes just another dependency that is automatically fetched. A simple check 
to make sure the Gradle version is okay can be coded into the build script, 
e.g. something like:

def blessed_gradle_version = '4.3'
task wrapper(type: Wrapper) {
  gradleVersion = blessed_gradle_version
}
if (project.gradle.gradleVersion != blessed_gradle_version) {
  println "Build expects ${blessed_gradle_version} but found 
${project.gradle.gradleVersion}\n Run 'gradle wrapper', then use 'gradlew'"
} else {
  apply from: 'real_build.gradle'
}

Gradle incompatibilities should be rare anyway.

What I would really like to see, and I know I’m asking for a lot, is the 
elimination of the Cygwin requirement and the use of the Gradle native plugin 
for the native code (maybe we can exclude WebKit from that for now)
You shouldn’t need Ant either.

It should be easy to build without WebKit and have pre-built WebKit binaries 
pulled in like any other dependency instead, based on a build property. E.g. 
gradlew -PusePrebuiltWebKit=true

Regards,

Scott

> On Dec 19, 2017, at 4:17 PM, Kevin Rushforth  
> wrote:
> 
> Building WebKit is challenging, to be sure. I hope to enlist the help of some 
> of our WebKit team members to review (and contribute to) update build 
> instructions to help make it a little less painful, but it is still a 
> challenge.
> 
> As for the moving version of gradle, we so far have settled on a specific 
> version for each release family: gradle 1.8 for JDK 8u, 3.1 for JDK 9, and 
> 4.3 for JDK 10. We don't tend to bump it.
> 
> Thanks for the feedback.
> 
> -- Kevin
> 
> 
> Mario Torre wrote:
>> For me the most intricate part is about building the webkit based
>> code, especially on RHEL/CentOS. I admit I didn't try with the very
>> latest code drop though. The moving version of Gradle is also an
>> issue, since we try to use a stable toolchain on those OSes.
>> 
>> Cheers,
>> Mario
>> 
>> 2017-12-19 21:11 GMT+01:00 Phil Race :
>>  
>>> In the "innovation" email thread it was suggested that one obstacle to
>>> getting involved and contributing to OpenJFX is just building it.
>>> 
>>> So what are the top one or two pain points with building OpenJFX today ?
>>> 
>>> - Insufficient or out-dated build docs ?
>>> - Tool-chain configuration problems - platform-specific or otherwise ?
>>> - Needing to do a JDK build as well (JDK 9 and later) ?
>>> - Something else ?
>>> 
>>> And having identified your pain point(s), what do you think would be a
>>> solution ?
>>> 
>>> -phil.

Re: Building OpenJFX.

[Johan Vos]

To be honest, building OpenJFX is the least of my worries. Compared with
other frameworks, building OpenJFX is extremely easy and well-documented.
The wiki pages are still mostly accurate.

I agree with Mario about the webkit: that is the biggest pain imho. The
fact that a bunch of code is dropped every now and then doesn't make it
easy.
Also, it takes a very long time to build those sources. On Android and iOS,
we don't have that problem as we leverage the webkit libraries that are
available on those platforms. It would be great if we could do something
similar on desktop (link instead of compile).

About the gradle moving target: OpenJFX has for a VERY long time been on
gradle 1.8. The recent changes were, as I see it, required to keep up with
the gradle/Java9 catchup.
For Android and iOS, I took the build.gradle from OpenJFX 10 and build with
a released Java 9, and that works perfect. I think the gradle bumps will be
less now.

- Johan

On Tue, Dec 19, 2017 at 9:22 PM Phil Race  wrote:

> In the "innovation" email thread it was suggested that one obstacle to
> getting involved and contributing to OpenJFX is just building it.
>
> So what are the top one or two pain points with building OpenJFX today ?
>
> - Insufficient or out-dated build docs ?
> - Tool-chain configuration problems - platform-specific or otherwise ?
> - Needing to do a JDK build as well (JDK 9 and later) ?
> - Something else ?
>
> And having identified your pain point(s), what do you think would be a
> solution ?
>
> -phil.
>

Re: Building OpenJFX.

[Kevin Rushforth]

Building WebKit is challenging, to be sure. I hope to enlist the help of 
some of our WebKit team members to review (and contribute to) update 
build instructions to help make it a little less painful, but it is 
still a challenge.


As for the moving version of gradle, we so far have settled on a 
specific version for each release family: gradle 1.8 for JDK 8u, 3.1 for 
JDK 9, and 4.3 for JDK 10. We don't tend to bump it.


Thanks for the feedback.

-- Kevin


Mario Torre wrote:

For me the most intricate part is about building the webkit based
code, especially on RHEL/CentOS. I admit I didn't try with the very
latest code drop though. The moving version of Gradle is also an
issue, since we try to use a stable toolchain on those OSes.

Cheers,
Mario

2017-12-19 21:11 GMT+01:00 Phil Race :
  

In the "innovation" email thread it was suggested that one obstacle to
getting involved and contributing to OpenJFX is just building it.

So what are the top one or two pain points with building OpenJFX today ?

- Insufficient or out-dated build docs ?
- Tool-chain configuration problems - platform-specific or otherwise ?
- Needing to do a JDK build as well (JDK 9 and later) ?
- Something else ?

And having identified your pain point(s), what do you think would be a
solution ?

-phil.





  

Re: Building OpenJFX.

[Mario Torre]

For me the most intricate part is about building the webkit based
code, especially on RHEL/CentOS. I admit I didn't try with the very
latest code drop though. The moving version of Gradle is also an
issue, since we try to use a stable toolchain on those OSes.

Cheers,
Mario

2017-12-19 21:11 GMT+01:00 Phil Race :
> In the "innovation" email thread it was suggested that one obstacle to
> getting involved and contributing to OpenJFX is just building it.
>
> So what are the top one or two pain points with building OpenJFX today ?
>
> - Insufficient or out-dated build docs ?
> - Tool-chain configuration problems - platform-specific or otherwise ?
> - Needing to do a JDK build as well (JDK 9 and later) ?
> - Something else ?
>
> And having identified your pain point(s), what do you think would be a
> solution ?
>
> -phil.



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Building OpenJFX.

[Laurent Bourgès]

Phil,
I am using ubuntu 17.4 (soon will upgrade to 17.10) and gcc 6 is the
default compiler.

I submitted a jfx bug as I had to fix some c code (wait call) and ignore
warnings (as error) to build OpenJFX / JDK 10 on gcc6.

I may help fixing some warnings but I am not an expert of javafx native
code so I can give you at least the complete list of gcc warnings.

My 2 cents...
Cheers,
Laurent

Le 19 déc. 2017 21:12, "Phil Race"  a écrit :

> In the "innovation" email thread it was suggested that one obstacle to
> getting involved and contributing to OpenJFX is just building it.
>
> So what are the top one or two pain points with building OpenJFX today ?
>
> - Insufficient or out-dated build docs ?
> - Tool-chain configuration problems - platform-specific or otherwise ?
> - Needing to do a JDK build as well (JDK 9 and later) ?
> - Something else ?
>
> And having identified your pain point(s), what do you think would be a
> solution ?
>
> -phil.
>

Building OpenJFX.

[Phil Race]

In the "innovation" email thread it was suggested that one obstacle to
getting involved and contributing to OpenJFX is just building it.

So what are the top one or two pain points with building OpenJFX today ?

- Insufficient or out-dated build docs ?
- Tool-chain configuration problems - platform-specific or otherwise ?
- Needing to do a JDK build as well (JDK 9 and later) ?
- Something else ?

And having identified your pain point(s), what do you think would be a 
solution ?


-phil.

[10] Review request: 8193823: gradle test fails to run when using jdk-10+36 as boot JDK

[Kevin Rushforth]

Phil,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8193823
http://cr.openjdk.java.net/~kcr/8193823/webrev.00/

This will allow us to continue to build with the latest JDK and works 
around a gradle bug that was exposed with the time-based version string 
changes for JEP-322 that went into jdk-10+36.


-- Kevin