I tend to agree. How about --with-sdk-name=<name>? SDKROOT implies a path, as would something like --with-sdk (and I could see that being confusing for someone building on Windows.
I got successful builds on Friday. I'll make the above changes and post another iteration for review. -DrD- > It looks to me like that we can remove the option in jdk9 since it was > deprecated in 8. It's a noop anyway though so shouldn't interfere with your > work. > > I'm not sure if giving --with-sysroot an optional special format for macosx > is the right way to go. It looks cleaner from one way, but also increases > confusion I think. I prefer a special parameter, which helps setting sysroot > as suggested. > > If you need a synonym for SYSROOT in macosx, that seems fine to me. > > /Erik > > On 2014-05-23 18:38, David DeHaven wrote: >> I'm combining this fix with another as it was starting to make my head split >> trying to keep the two separate, they're just too closely related. I'll >> start another review thread for the combined patches. >> >> -DrD- >> >>> 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- >>>>>> >
