This is now a combined fix for:
https://bugs.openjdk.java.net/browse/JDK-8043591
https://bugs.openjdk.java.net/browse/JDK-8043340
Since a picture is worth 10,000 words (build systems are 10x as complicated as
anything else in life) here's an ASCII flow chart showing the SYSROOT logic I
have now:
+---------+
| SYSROOT |Y
| set? +-------------------+
+----+----+ |
|N |
| |
| |
+-++-v--+---+------+ |
Y| --with-sdk-name? | |
+---+ | |
| +----+-------------+ |
| |N |
| | |
| +----v--------+ +---------+ |
| | SDKROOT |Y | SYSROOT | |
| | set in env? +---> = +->
| | | | SDKROOT | |
| +---+---------+ +---------+ |
| |N |
| +---v---------+ |
| | SDKNAME | |
| | = | |
| | macosx | |
| +---+---------+ |
| | |
| | |
| +---v-------------+ |
| | Call xcodebuild | |
| | to determine | |
+---> SYSROOT | |
+--------------+--+ |
| |
+---v------+ |
| Validate | |
| SYSROOT <-------+
+----------+
So xcodebuild will only be called if a SDK name is provided or neither SYSROOT
nor SDKROOT (which must be filesystem paths) are set. The end result is we
always have SYSROOT set to some path. If we get to "Validate SYSROOT" and
SYSROOT is not set, then we have an error that needs to be addressed (or the
user has a misconfigured environment). Only SDKROOT and SYSROOT will be
exported.
I did have to move XCODEBUILD detection to basics.m4, it was either that or add
basically duplicate code to run the right xcodebuild tool.
Here's the latest patch set:
http://cr.openjdk.java.net/~ddehaven/8043340/v2/
We'll need a followup issue to clean up all the warnings that clang is now
spitting out when building jdk...
-DrD-
> I think --with-sdk-name sounds good. Just make sure to document it very
> clearly to minimize confusion between --with-sysroot --with-devkit and
> --with-tools-path. We are gathering quite a few related options here.
>
> If this new option is used to set sysroot, then it should probably move
> closer to the sysroot setting, which is setup in BASIC_SETUP_DEVKIT. I
> realize you then need to find xcodebuild there already, using the
> TOOLCHAIN_PATH, but I think that's ok, since that tools is used specifically
> for finding a sysroot on mac.
>
> Overall, I like where this is going.
>
> /Erik
>
> On 2014-05-27 18:29, David DeHaven wrote:
>> 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-
>>>>>>>>
>
