8324185: [8u] Accept Xcode 12+ builds on macOS

[mrserb]

I would like to update the build logic for macOS so it will accept the XCode 14 and 15. It could be done in a few ways:

• Add XCode 13, 14 and 15 to the list of supported versions, like this
• Accept all XCode 9+ versions, like this.
• Delete the "fail fast" code path. So if the xcode and command-line tools are there then build it, like this.

I think we can safely delete this check, so this PR implements it.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8324185 needs maintainer approval

Issue

• JDK-8324185: [8u] Accept Xcode 12+ builds on macOS (Bug - P3 - Approved)

Reviewers

• Paul Hohensee (@phohensee - Reviewer)
• Andrew John Hughes (@gnu-andrew - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/422/head:pull/422
$ git checkout pull/422

Update a local copy of the PR:
$ git checkout pull/422
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/422/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 422

View PR using the GUI difftool:
$ git pr show -t 422

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/422.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back serb! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[mlbridge]

Webrevs

• 03: Full (00eacf38)
• 02: Full (091248d5)
• 01: Full - Incremental (78f31934)
• 00: Full (d28f6cdb)

[phohensee]

I'd go with the second alternative so as keep the error message.

[benty-amzn]

Option 3 is closest to what newer versions do. It's quite difficult at this point to get a system with XCode 9 up and running, much less 6, so the error message is likely to never be relevant. I think either option 2 or 3 is fine.

[phohensee]

Let's go with option 3 if that's what's closest to current practice.

[openjdk]

⚠️ @mrserb This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[openjdk]

@mrserb This change now passes all automated pre-integration checks.

After integration, the commit message for the final commit will be:

8324185: [8u] Accept Xcode 12+ builds on macOS

Reviewed-by: phh, andrew

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 19 new commits pushed to the master branch:

• c6ba33e: 8329544: [8u] sun/security/krb5/auto/ReplayCacheTestProc.java cannot find the testlibrary
• cde8aca: 8069389: CompilerOracle prefix wildcarding is broken for long strings
• c1c8064: 8320005: Allow loading of shared objects with .a extension on AIX
• d0d9a15: 8291638: Keep-Alive timeout of 0 should close connection immediately
• 1db6a76: 8203691: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails
• a4b40e8: 8291226: Create Test Cases to cover scenarios for JDK-8278067
• af033c6: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074
• 66fa62a: 8325927: [8u] Backport of JDK-8170552 missed part of the test
• 5968b15: 8328809: [8u] Problem list some CA tests
• e72ea2d: 8317507: C2 compilation fails with "Exceeded _node_regs array"
• ... and 9 more: https://git.openjdk.org/jdk8u-dev/compare/1fad52dc04938f9aae3fa372632011bcaf80b265...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[bridgekeeper]

@mrserb This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[gnu-andrew]

I agree removal is appropriate here. These kind of version tests serve no real purpose in the first place. If one is trying to get the JDK to build with a new XCode version, this check is just a blocker that has to be removed to get to the real issues and actually have something to work with to add support. If the aim is to avoid a specific bug, or check for a specific feature, then the check should be for the bug or feature (see what we do with flags for GCC)

The thing I was most curious about with this PR was why it wasn't a backport from later versions. It seems that JDK-8043340 was implemented differently in 8u and 9. In the 9 version this check is not added. It is unique to the 8 version, restricting it to XCode 4. @benty-amzn's later change just extended it to more versions.

[gnu-andrew]

/approve yes

[openjdk]

@gnu-andrew
8324185: The approval request has been approved.

[mrserb]

/integrate

[openjdk]

Going to push as commit 0f59d5c.
Since your change was applied there have been 19 commits pushed to the master branch:

• c6ba33e: 8329544: [8u] sun/security/krb5/auto/ReplayCacheTestProc.java cannot find the testlibrary
• cde8aca: 8069389: CompilerOracle prefix wildcarding is broken for long strings
• c1c8064: 8320005: Allow loading of shared objects with .a extension on AIX
• d0d9a15: 8291638: Keep-Alive timeout of 0 should close connection immediately
• 1db6a76: 8203691: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails
• a4b40e8: 8291226: Create Test Cases to cover scenarios for JDK-8278067
• af033c6: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074
• 66fa62a: 8325927: [8u] Backport of JDK-8170552 missed part of the test
• 5968b15: 8328809: [8u] Problem list some CA tests
• e72ea2d: 8317507: C2 compilation fails with "Exceeded _node_regs array"
• ... and 9 more: https://git.openjdk.org/jdk8u-dev/compare/1fad52dc04938f9aae3fa372632011bcaf80b265...master

Your commit was automatically rebased without conflicts.

[openjdk]

@mrserb Pushed as commit 0f59d5c.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.