Nobody should be using this any more, can I nuke it? BASIC_DEPRECATED_ARG_ENABLE(macosx-runtime-support, macosx_runtime_support)
That hasn't done anything since JDK7, it was deprecated in 8 and shouldn't even be used in 8. -DrD- > > Now that my mind is fresher and I've had my coffee... (and someones poked me > in the ribs ;) > > MACOSX_SDK_PATH should be SDKROOT, which is what Apple uses when building via > Xcode or xcodebuild, which would also promote that setting to the few > remaining Xcode projects we have hanging around. We can use SYSROOT, but > Apple's tools will just ignore it so I propose we add SDKROOT as a synonym > for SYSROOT. Unfortunately the -F arguments still need to be absolute paths. > > We can eliminate the hard coded ApplicationServices paths by including > ApplicationServices instead of it's sub-frameworks (and adjust the source > accordingly), but we can't do that for JavaVM as we absolutely do NOT want to > link against JavaVM, only JNF and JRS. > > > We'll do something like: > > # assuming SYSROOT="$with_sysroot" already > if test "x$OPENJDK_TARGET_OS" = xmacosx; then > if test ! -d "$SYSROOT"; then > # SYSROOT is not a directory, check if it's a symbolic name for an Xcode > SDK > SYSROOT=`$(XCODEBUILD) -sdk "$SYSROOT" -version | grep '^Path: ' | sed > 's/Path: //'` > if test ! -d "$SYSROOT"; then > AC_MSG_ERROR([SYSROOT does not point to a valid path]) > fi > fi > SDKROOT=$SYSROOT > AC_SUBST(SDKROOT) > fi > > This will eliminate any added configure arguments. > > (14 hours of build system hacking makes for a very muddled mind...) > > -DrD- > > >> Hello David, >> >> I like that you incorporate the existing sysroot settings for this. I wonder >> though, what is the difference between --with-macosx-sdk-path and >> --with-sysroot? Do we really need two parameters for this? If it's actually >> a sysroot, couldn't we replace all uses of this variable with just SYSROOT >> and keep it more generic? >> >> /Erik >> >> On 2014-05-23 08:16, David DeHaven wrote: >>> Build systems take such a long time work on... >>> >>> I've changed the logic, I think for the better. I hijacked --with-sysroot, >>> SYSROOT is set to the SDK path and I stuffed the -iframework argument >>> alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now >>> the only change that's peppered throughout the forest is adding >>> $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and >>> ApplicationServices.framework paths, not to mention everything gets >>> -isysroot/-iframework and not just the parts that needed JavaVM or >>> ApplicationServices. The added SYSROOT logic is Mac specific so other >>> platforms should be unaffected, JPRT should tell otherwise if not... >>> >>> I also added two configure args: >>> --with-macosx-sdk name of Mac OS X SDK to build with, e.g., >>> macosx10.7 >>> [macosx] >>> --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] >> >>> Please note that this version is against jdk9-dev with the following >>> patches imported from other forests: >>> hotspot: >>> JDK-8043164 (jdk9/hs) >>> >>> jdk: >>> JDK-8042440 (jdk9/client) >>> JDK-8043646 (jdk9/client) >>> JDK-8003900 (jdk9/client) >>> >>> >>> Updated patches: >>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/base >>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot >>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk >>> >>> -DrD- >>> >> >
