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 <swpal...@gmail.com> 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
