Re: Gradle Scripts
I've filed: https://javafx-jira.kenai.com/browse/RT-37293 With a couple suggestions for fixes. Scott On Tue, May 27, 2014 at 1:54 PM, Kevin Rushforth wrote: > >> *** I have updated to the 8u5-b13 tag as that is what I was patching. >> Perhaps this is the step that puts things out of date? *** > > > Yes, that would be it, since it would not contain the fix for: > >RT-36163: Cannot build JavaFX using JDK 8u20 or JDK 9 > > (same bug would affect building with 8u5) > > Disabling the min build check will be a fine workaround. > > >> Gradle 1.12 fails to build it. I don't understand how the >> defineProperty() method can possibly work, as it is out of scope from >> windows.gradle and mac.gradle scripts. I encountered this on both >> Windows and Mac. > > > It does look like there are issues in building with 1.12 -- a closed build > falls over and dies even earlier (before buildSrc is compiled). If you would > like to file a JIRA we can look into it for 8u40. It would be great to fix > the scripts so it works with 1.8 and 1.12. > > > -- Kevin > > > Scott Palmer wrote: >> >> I am using a clone of http://hg.openjdk.java.net/openjfx/8u-dev/rt/ >> >> *** I have updated to the 8u5-b13 tag as that is what I was patching. >> Perhaps this is the step that puts things out of date? *** >> If that's the case I can just hack the min build check as I already have. >> >> Gradle 1.12 fails to build it. I don't understand how the >> defineProperty() method can possibly work, as it is out of scope from >> windows.gradle and mac.gradle scripts. I encountered this on both >> Windows and Mac. >> >> Interesting point about checking in gradle-wrapper.jar. I do believe >> it is under the Apache License V2.0... I understand how you must be >> careful. You could probably do something clever to add a small script >> that would download it from gradle.org for setting up the initial >> workspace, rather than checking it in. >> >> I created https://javafx-jira.kenai.com/browse/RT-37290 to cover the >> Cygwin issue. >> >> The wiki needs to be updated as it claims: "Invoking gradle without >> any additional parameters will skip the building of all native code." >> See: >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest >> >> According to the wiki there already is a flag for controlling the >> build of the native parts: "-PBUILD_NATIVES=true" >> >> I've field: https://javafx-jira.kenai.com/browse/RT-37291 >> >> [Steve's message just came in as I was about to press send, thanks! >> You can update the issue as necessary.] >> >> Cheers, >> >> Scott >> >> On Tue, May 27, 2014 at 1:05 PM, Kevin Rushforth >> wrote: >> >>> >>> I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you >>> have an out-of-date repo. >>> >>> -- Kevin >>> >>> >>> >>> Kevin Rushforth wrote: >>> Hi Scott, I don't think we can use gradle wrapper since it would require checking a gradle jar file into our repo (there is IP / licensing concern with that). Regarding your other issues: 1) The Mac issue is a known problem that I still plan to address for 8u20: https://javafx-jira.kenai.com/browse/RT-34388 2) In the short term we are unlikely to change our production build to a newer version of gradle, but I know of no reason it won't work with gradle 1.12 (gradle 1.11 is known not to work). Does it build for you with 1.12? I will try it myself. 3) The version check should work fine with JDK 8u5. Are you cloning openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this has been tested, but I will double-check. 4) Yes, we expect cygwin -- mainly for native but also for some of our legacy any scripts (mostly in closed). We could consider accepting patches that checked whether a windows build was cygwin and allowed it to build at least the java code without requiring Cygwin. Did you want to file a JIRA for this? 5) Native compilation for everything except media and wekbit, is on by default, and there is currently no easy way to disable it. This is something Richard had wanted to change back when the gradle build scripts were developed, but was not finished. At the least, a flag to turn off native compilation would be good. Do you want to file a JIRA for this? -- Kevin Scott Palmer wrote: > > I know the wiki says only Gradle 1.8 is "guaranteed to work" so I have > to > ask: > Why not use the Gradle Wrapper to force use of 1.8? > http://www.gradle.org/docs/current/userguide/gradle_wrapper.html > > Well, I tried tweaking the build scripts to use it myself, running on > OS X and found that the scripts appear to be badly broken anyway and > they can't even be parsed with later Gradle versions so you can't even > run the wrapper ta
Re: Gradle Scripts
*** I have updated to the 8u5-b13 tag as that is what I was patching. Perhaps this is the step that puts things out of date? *** Yes, that would be it, since it would not contain the fix for: RT-36163: Cannot build JavaFX using JDK 8u20 or JDK 9 (same bug would affect building with 8u5) Disabling the min build check will be a fine workaround. Gradle 1.12 fails to build it. I don't understand how the defineProperty() method can possibly work, as it is out of scope from windows.gradle and mac.gradle scripts. I encountered this on both Windows and Mac. It does look like there are issues in building with 1.12 -- a closed build falls over and dies even earlier (before buildSrc is compiled). If you would like to file a JIRA we can look into it for 8u40. It would be great to fix the scripts so it works with 1.8 and 1.12. -- Kevin Scott Palmer wrote: I am using a clone of http://hg.openjdk.java.net/openjfx/8u-dev/rt/ *** I have updated to the 8u5-b13 tag as that is what I was patching. Perhaps this is the step that puts things out of date? *** If that's the case I can just hack the min build check as I already have. Gradle 1.12 fails to build it. I don't understand how the defineProperty() method can possibly work, as it is out of scope from windows.gradle and mac.gradle scripts. I encountered this on both Windows and Mac. Interesting point about checking in gradle-wrapper.jar. I do believe it is under the Apache License V2.0... I understand how you must be careful. You could probably do something clever to add a small script that would download it from gradle.org for setting up the initial workspace, rather than checking it in. I created https://javafx-jira.kenai.com/browse/RT-37290 to cover the Cygwin issue. The wiki needs to be updated as it claims: "Invoking gradle without any additional parameters will skip the building of all native code." See: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest According to the wiki there already is a flag for controlling the build of the native parts: "-PBUILD_NATIVES=true" I've field: https://javafx-jira.kenai.com/browse/RT-37291 [Steve's message just came in as I was about to press send, thanks! You can update the issue as necessary.] Cheers, Scott On Tue, May 27, 2014 at 1:05 PM, Kevin Rushforth wrote: I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you have an out-of-date repo. -- Kevin Kevin Rushforth wrote: Hi Scott, I don't think we can use gradle wrapper since it would require checking a gradle jar file into our repo (there is IP / licensing concern with that). Regarding your other issues: 1) The Mac issue is a known problem that I still plan to address for 8u20: https://javafx-jira.kenai.com/browse/RT-34388 2) In the short term we are unlikely to change our production build to a newer version of gradle, but I know of no reason it won't work with gradle 1.12 (gradle 1.11 is known not to work). Does it build for you with 1.12? I will try it myself. 3) The version check should work fine with JDK 8u5. Are you cloning openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this has been tested, but I will double-check. 4) Yes, we expect cygwin -- mainly for native but also for some of our legacy any scripts (mostly in closed). We could consider accepting patches that checked whether a windows build was cygwin and allowed it to build at least the java code without requiring Cygwin. Did you want to file a JIRA for this? 5) Native compilation for everything except media and wekbit, is on by default, and there is currently no easy way to disable it. This is something Richard had wanted to change back when the gradle build scripts were developed, but was not finished. At the least, a flag to turn off native compilation would be good. Do you want to file a JIRA for this? -- Kevin Scott Palmer wrote: I know the wiki says only Gradle 1.8 is "guaranteed to work" so I have to ask: Why not use the Gradle Wrapper to force use of 1.8? http://www.gradle.org/docs/current/userguide/gradle_wrapper.html Well, I tried tweaking the build scripts to use it myself, running on OS X and found that the scripts appear to be badly broken anyway and they can't even be parsed with later Gradle versions so you can't even run the wrapper task: The error is: Could not find method 'defineProperty() for arguments [MACOSX_MIN_VERSION, 10.7] on root project . Sure enough the defineProperty method is being called from a different .gradle file than the one in which it is defined, so it is out of scope. I corrected this locally by changing it to a closure and assigning it to project.ext.defineProperty. Then I added: task wrapper(type: Wrapper) { gradleVersion = 1.8' } and was able to get the gradlew script created by running: gradle wrapper So then I tried to build with Gradle 1.8 by running: ./gradlew Then I hit :verifyJava complaining that the
Re: Gradle Scripts
I am using a clone of http://hg.openjdk.java.net/openjfx/8u-dev/rt/ *** I have updated to the 8u5-b13 tag as that is what I was patching. Perhaps this is the step that puts things out of date? *** If that's the case I can just hack the min build check as I already have. Gradle 1.12 fails to build it. I don't understand how the defineProperty() method can possibly work, as it is out of scope from windows.gradle and mac.gradle scripts. I encountered this on both Windows and Mac. Interesting point about checking in gradle-wrapper.jar. I do believe it is under the Apache License V2.0... I understand how you must be careful. You could probably do something clever to add a small script that would download it from gradle.org for setting up the initial workspace, rather than checking it in. I created https://javafx-jira.kenai.com/browse/RT-37290 to cover the Cygwin issue. The wiki needs to be updated as it claims: "Invoking gradle without any additional parameters will skip the building of all native code." See: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest According to the wiki there already is a flag for controlling the build of the native parts: "-PBUILD_NATIVES=true" I've field: https://javafx-jira.kenai.com/browse/RT-37291 [Steve's message just came in as I was about to press send, thanks! You can update the issue as necessary.] Cheers, Scott On Tue, May 27, 2014 at 1:05 PM, Kevin Rushforth wrote: > I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you > have an out-of-date repo. > > -- Kevin > > > > Kevin Rushforth wrote: >> >> Hi Scott, >> >> I don't think we can use gradle wrapper since it would require checking a >> gradle jar file into our repo (there is IP / licensing concern with that). >> >> Regarding your other issues: >> >> 1) The Mac issue is a known problem that I still plan to address for 8u20: >> https://javafx-jira.kenai.com/browse/RT-34388 >> >> 2) In the short term we are unlikely to change our production build to a >> newer version of gradle, but I know of no reason it won't work with gradle >> 1.12 (gradle 1.11 is known not to work). Does it build for you with 1.12? I >> will try it myself. >> >> 3) The version check should work fine with JDK 8u5. Are you cloning >> openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this has >> been tested, but I will double-check. >> >> 4) Yes, we expect cygwin -- mainly for native but also for some of our >> legacy any scripts (mostly in closed). We could consider accepting patches >> that checked whether a windows build was cygwin and allowed it to build at >> least the java code without requiring Cygwin. Did you want to file a JIRA >> for this? >> >> 5) Native compilation for everything except media and wekbit, is on by >> default, and there is currently no easy way to disable it. This is something >> Richard had wanted to change back when the gradle build scripts were >> developed, but was not finished. At the least, a flag to turn off native >> compilation would be good. Do you want to file a JIRA for this? >> >> -- Kevin >> >> >> Scott Palmer wrote: >>> >>> I know the wiki says only Gradle 1.8 is "guaranteed to work" so I have to >>> ask: >>> Why not use the Gradle Wrapper to force use of 1.8? >>> http://www.gradle.org/docs/current/userguide/gradle_wrapper.html >>> >>> Well, I tried tweaking the build scripts to use it myself, running on >>> OS X and found that the scripts appear to be badly broken anyway and >>> they can't even be parsed with later Gradle versions so you can't even >>> run the wrapper task: >>> >>> The error is: >>> >>> Could not find method 'defineProperty() for arguments >>> [MACOSX_MIN_VERSION, 10.7] on root project . >>> >>> Sure enough the defineProperty method is being called from a different >>> .gradle file than the one in which it is defined, so it is out of >>> scope. I corrected this locally by changing it to a closure and >>> assigning it to project.ext.defineProperty. Then I added: >>> >>> task wrapper(type: Wrapper) { >>> gradleVersion = 1.8' >>> } >>> >>> and was able to get the gradlew script created by running: >>> >>> gradle wrapper >>> >>> So then I tried to build with Gradle 1.8 by running: >>> >>> ./gradlew >>> >>> Then I hit :verifyJava complaining that the build number (13) was too >>> low (< 115)... but I'm building the 8u5 code with the 8u5 release... >>> that seems like a combination that should work. >>> >>> I think everyone (myself included) would be more inclined to help with >>> patches if it wasn't such a pain to build. I appreciate that prior to >>> the use of Gradle this was likely much worse. Gradle is a great build >>> system and should be able to make this an even simpler process. >>> >>> On Windows for what I assume are historical reasons, Cygwin is >>> expected. I'm only trying to build the Java side of things.. not the >>> native DLLs and I don't see Cygwin doing anything of value in the
Re: Gradle Scripts
BUILD_NATIVES was never implemented so I deleted mention of it from the wiki. I have also updated the Mac section to include MACOSX_MIN_VERSION. I could have swore this information was there but apparently not. Steve On 2014-05-27, 12:22 PM, Scott Palmer wrote: My build woes continued a bit... I tweaked build.gradle such that the buildnum.min was 5. Then the build failed trying to build :fxpackager:compileLauncher Coud not call NativeCompileTask.compile() on task ':fxpackager:compileLauncher' I belive this is native code? The wiki says that native code doesnt' normally build unless you use -PBUILD_NATIVES=true I imagine this is true for the FX runtime DLLs and was just overlooked for the launcher. The root cause seems to be that I am missing the OS X 10.7 SDK: clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' But I do have later versions for 10.8 and 10.9. Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me to finally complete a successful build! - I think I haven't tested anything yet.. but at least gradle stopped complaining. Cheers, Scott On Tue, May 27, 2014 at 11:56 AM, Scott Palmer wrote: I know the wiki says only Gradle 1.8 is "guaranteed to work" so I have to ask: Why not use the Gradle Wrapper to force use of 1.8? http://www.gradle.org/docs/current/userguide/gradle_wrapper.html Well, I tried tweaking the build scripts to use it myself, running on OS X and found that the scripts appear to be badly broken anyway and they can't even be parsed with later Gradle versions so you can't even run the wrapper task: The error is: Could not find method 'defineProperty() for arguments [MACOSX_MIN_VERSION, 10.7] on root project . Sure enough the defineProperty method is being called from a different .gradle file than the one in which it is defined, so it is out of scope. I corrected this locally by changing it to a closure and assigning it to project.ext.defineProperty. Then I added: task wrapper(type: Wrapper) { gradleVersion = 1.8' } and was able to get the gradlew script created by running: gradle wrapper So then I tried to build with Gradle 1.8 by running: ./gradlew Then I hit :verifyJava complaining that the build number (13) was too low (< 115)... but I'm building the 8u5 code with the 8u5 release... that seems like a combination that should work. I think everyone (myself included) would be more inclined to help with patches if it wasn't such a pain to build. I appreciate that prior to the use of Gradle this was likely much worse. Gradle is a great build system and should be able to make this an even simpler process. On Windows for what I assume are historical reasons, Cygwin is expected. I'm only trying to build the Java side of things.. not the native DLLs and I don't see Cygwin doing anything of value in the build scripts for that case. It's mangling paths that don't need to be mangle for example. I think the build scripts could be cleaned up to provide a much smoother build experience for those outside of Oracle. No doubt you guys simply don't have the cycles to burn on fixing build scripts that are currently working for you.. but I suspect it will pay off in the long run. The current version of Gradle, 1.12, is the last 1.x Gradle release before the 2.x versions appear. It may make sense to achieve compatibility with it. Gradle 2.x is expected to break things, but once things are working with 1.12, then you can work on getting rid of the warnings and you will be in a much better position. Cheers, Scott
Re: Gradle Scripts
I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you have an out-of-date repo. -- Kevin Kevin Rushforth wrote: Hi Scott, I don't think we can use gradle wrapper since it would require checking a gradle jar file into our repo (there is IP / licensing concern with that). Regarding your other issues: 1) The Mac issue is a known problem that I still plan to address for 8u20: https://javafx-jira.kenai.com/browse/RT-34388 2) In the short term we are unlikely to change our production build to a newer version of gradle, but I know of no reason it won't work with gradle 1.12 (gradle 1.11 is known not to work). Does it build for you with 1.12? I will try it myself. 3) The version check should work fine with JDK 8u5. Are you cloning openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this has been tested, but I will double-check. 4) Yes, we expect cygwin -- mainly for native but also for some of our legacy any scripts (mostly in closed). We could consider accepting patches that checked whether a windows build was cygwin and allowed it to build at least the java code without requiring Cygwin. Did you want to file a JIRA for this? 5) Native compilation for everything except media and wekbit, is on by default, and there is currently no easy way to disable it. This is something Richard had wanted to change back when the gradle build scripts were developed, but was not finished. At the least, a flag to turn off native compilation would be good. Do you want to file a JIRA for this? -- Kevin Scott Palmer wrote: I know the wiki says only Gradle 1.8 is "guaranteed to work" so I have to ask: Why not use the Gradle Wrapper to force use of 1.8? http://www.gradle.org/docs/current/userguide/gradle_wrapper.html Well, I tried tweaking the build scripts to use it myself, running on OS X and found that the scripts appear to be badly broken anyway and they can't even be parsed with later Gradle versions so you can't even run the wrapper task: The error is: Could not find method 'defineProperty() for arguments [MACOSX_MIN_VERSION, 10.7] on root project . Sure enough the defineProperty method is being called from a different .gradle file than the one in which it is defined, so it is out of scope. I corrected this locally by changing it to a closure and assigning it to project.ext.defineProperty. Then I added: task wrapper(type: Wrapper) { gradleVersion = 1.8' } and was able to get the gradlew script created by running: gradle wrapper So then I tried to build with Gradle 1.8 by running: ./gradlew Then I hit :verifyJava complaining that the build number (13) was too low (< 115)... but I'm building the 8u5 code with the 8u5 release... that seems like a combination that should work. I think everyone (myself included) would be more inclined to help with patches if it wasn't such a pain to build. I appreciate that prior to the use of Gradle this was likely much worse. Gradle is a great build system and should be able to make this an even simpler process. On Windows for what I assume are historical reasons, Cygwin is expected. I'm only trying to build the Java side of things.. not the native DLLs and I don't see Cygwin doing anything of value in the build scripts for that case. It's mangling paths that don't need to be mangle for example. I think the build scripts could be cleaned up to provide a much smoother build experience for those outside of Oracle. No doubt you guys simply don't have the cycles to burn on fixing build scripts that are currently working for you.. but I suspect it will pay off in the long run. The current version of Gradle, 1.12, is the last 1.x Gradle release before the 2.x versions appear. It may make sense to achieve compatibility with it. Gradle 2.x is expected to break things, but once things are working with 1.12, then you can work on getting rid of the warnings and you will be in a much better position. Cheers, Scott
Re: Gradle Scripts
Hi Scott, I don't think we can use gradle wrapper since it would require checking a gradle jar file into our repo (there is IP / licensing concern with that). Regarding your other issues: 1) The Mac issue is a known problem that I still plan to address for 8u20: https://javafx-jira.kenai.com/browse/RT-34388 2) In the short term we are unlikely to change our production build to a newer version of gradle, but I know of no reason it won't work with gradle 1.12 (gradle 1.11 is known not to work). Does it build for you with 1.12? I will try it myself. 3) The version check should work fine with JDK 8u5. Are you cloning openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this has been tested, but I will double-check. 4) Yes, we expect cygwin -- mainly for native but also for some of our legacy any scripts (mostly in closed). We could consider accepting patches that checked whether a windows build was cygwin and allowed it to build at least the java code without requiring Cygwin. Did you want to file a JIRA for this? 5) Native compilation for everything except media and wekbit, is on by default, and there is currently no easy way to disable it. This is something Richard had wanted to change back when the gradle build scripts were developed, but was not finished. At the least, a flag to turn off native compilation would be good. Do you want to file a JIRA for this? -- Kevin Scott Palmer wrote: I know the wiki says only Gradle 1.8 is "guaranteed to work" so I have to ask: Why not use the Gradle Wrapper to force use of 1.8? http://www.gradle.org/docs/current/userguide/gradle_wrapper.html Well, I tried tweaking the build scripts to use it myself, running on OS X and found that the scripts appear to be badly broken anyway and they can't even be parsed with later Gradle versions so you can't even run the wrapper task: The error is: Could not find method 'defineProperty() for arguments [MACOSX_MIN_VERSION, 10.7] on root project . Sure enough the defineProperty method is being called from a different .gradle file than the one in which it is defined, so it is out of scope. I corrected this locally by changing it to a closure and assigning it to project.ext.defineProperty. Then I added: task wrapper(type: Wrapper) { gradleVersion = 1.8' } and was able to get the gradlew script created by running: gradle wrapper So then I tried to build with Gradle 1.8 by running: ./gradlew Then I hit :verifyJava complaining that the build number (13) was too low (< 115)... but I'm building the 8u5 code with the 8u5 release... that seems like a combination that should work. I think everyone (myself included) would be more inclined to help with patches if it wasn't such a pain to build. I appreciate that prior to the use of Gradle this was likely much worse. Gradle is a great build system and should be able to make this an even simpler process. On Windows for what I assume are historical reasons, Cygwin is expected. I'm only trying to build the Java side of things.. not the native DLLs and I don't see Cygwin doing anything of value in the build scripts for that case. It's mangling paths that don't need to be mangle for example. I think the build scripts could be cleaned up to provide a much smoother build experience for those outside of Oracle. No doubt you guys simply don't have the cycles to burn on fixing build scripts that are currently working for you.. but I suspect it will pay off in the long run. The current version of Gradle, 1.12, is the last 1.x Gradle release before the 2.x versions appear. It may make sense to achieve compatibility with it. Gradle 2.x is expected to break things, but once things are working with 1.12, then you can work on getting rid of the warnings and you will be in a much better position. Cheers, Scott
Re: Gradle Scripts
See https://javafx-jira.kenai.com/browse/RT-34388 On May 27, 2014, at 9:29 AM, David Hill wrote: > On 5/27/14, May 27, 12:22 PM, Scott Palmer wrote: >> >> The root cause seems to be that I am missing the OS X 10.7 SDK: >> >> clang: warning: no such sysroot directory: >> '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' >> >> But I do have later versions for 10.8 and 10.9. >> >> Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me >> to finally complete a successful build! - I think I haven't tested >> anything yet.. but at least gradle stopped complaining. > > When I ran into this, I symlinked MacOSX10.7.sdk to MacOSX10.8.sdk > Was told I could set the property MACOSX_MIN_VERSION on the command line, but > that got old quick :-) > > Dave > > -- > David Hill > Java Embedded Development > > "Experience is that marvelous thing that enables you to recognize a mistake > when you make it again." > -- Franklin P. Jones >
Re: Gradle Scripts
On 5/27/14, May 27, 12:22 PM, Scott Palmer wrote: The root cause seems to be that I am missing the OS X 10.7 SDK: clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' But I do have later versions for 10.8 and 10.9. Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me to finally complete a successful build! - I think I haven't tested anything yet.. but at least gradle stopped complaining. When I ran into this, I symlinked MacOSX10.7.sdk to MacOSX10.8.sdk Was told I could set the property MACOSX_MIN_VERSION on the command line, but that got old quick :-) Dave -- David Hill Java Embedded Development "Experience is that marvelous thing that enables you to recognize a mistake when you make it again." -- Franklin P. Jones
Re: Gradle Scripts
My build woes continued a bit... I tweaked build.gradle such that the buildnum.min was 5. Then the build failed trying to build :fxpackager:compileLauncher >Coud not call NativeCompileTask.compile() on task ':fxpackager:compileLauncher' I belive this is native code? The wiki says that native code doesnt' normally build unless you use -PBUILD_NATIVES=true I imagine this is true for the FX runtime DLLs and was just overlooked for the launcher. The root cause seems to be that I am missing the OS X 10.7 SDK: clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' But I do have later versions for 10.8 and 10.9. Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me to finally complete a successful build! - I think I haven't tested anything yet.. but at least gradle stopped complaining. Cheers, Scott On Tue, May 27, 2014 at 11:56 AM, Scott Palmer wrote: > I know the wiki says only Gradle 1.8 is "guaranteed to work" so I have to ask: > Why not use the Gradle Wrapper to force use of 1.8? > http://www.gradle.org/docs/current/userguide/gradle_wrapper.html > > Well, I tried tweaking the build scripts to use it myself, running on > OS X and found that the scripts appear to be badly broken anyway and > they can't even be parsed with later Gradle versions so you can't even > run the wrapper task: > > The error is: > > Could not find method 'defineProperty() for arguments > [MACOSX_MIN_VERSION, 10.7] on root project . > > Sure enough the defineProperty method is being called from a different > .gradle file than the one in which it is defined, so it is out of > scope. I corrected this locally by changing it to a closure and > assigning it to project.ext.defineProperty. Then I added: > > task wrapper(type: Wrapper) { > gradleVersion = 1.8' > } > > and was able to get the gradlew script created by running: > > gradle wrapper > > So then I tried to build with Gradle 1.8 by running: > > ./gradlew > > Then I hit :verifyJava complaining that the build number (13) was too > low (< 115)... but I'm building the 8u5 code with the 8u5 release... > that seems like a combination that should work. > > I think everyone (myself included) would be more inclined to help with > patches if it wasn't such a pain to build. I appreciate that prior to > the use of Gradle this was likely much worse. Gradle is a great build > system and should be able to make this an even simpler process. > > On Windows for what I assume are historical reasons, Cygwin is > expected. I'm only trying to build the Java side of things.. not the > native DLLs and I don't see Cygwin doing anything of value in the > build scripts for that case. It's mangling paths that don't need to > be mangle for example. > > I think the build scripts could be cleaned up to provide a much > smoother build experience for those outside of Oracle. > > No doubt you guys simply don't have the cycles to burn on fixing build > scripts that are currently working for you.. but I suspect it will pay > off in the long run. The current version of Gradle, 1.12, is the last > 1.x Gradle release before the 2.x versions appear. It may make sense > to achieve compatibility with it. Gradle 2.x is expected to break > things, but once things are working with 1.12, then you can work on > getting rid of the warnings and you will be in a much better position. > > > Cheers, > > Scott