shims/mac/super: add ruby shims to set SDKROOT

[Bo98]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?
• Have you successfully run brew man locally and committed any changes?

---

I think we're past the 5+ formulae threshold now.

System gem on Mojave is broken and can't build native extensions without SDKROOT.

As evidenced by #9410, the bug appears to have now spread to Catalina.

[BrewTestBot]

Review period will end on 2021-02-12 at 16:39:07 UTC.

[MikeMcQuaid]

Is this Xcode or CLT specific?

[Bo98]

Is this Xcode or CLT specific?

We mandate the CLT on older OS versions, and you indeed will need the CLT to get the correct SDK.

In terms of the bug, if xcode-select -p is:

• Xcode, then it'll point to the 10.15 SDK on Mojave or the 11 SDK on Catalina. Older SDKs are not available under Xcode.
• CLT, then it'll point to /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk which will symlink to the latest SDK - not the one matching the OS (so 10.15 SDK on Mojave, 11 SDK on Catalina).

Using a newer SDK is wrong as Ruby headers will be for a newer Darwin version (11 SDK has Ruby headers for darwin20 but Catalina is darwin19; and even worse 10.15 SDK has Ruby 2.6 headers while 10.14 uses Ruby 2.3).

The shims will point system Ruby to /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk and /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk for Mojave and Catalina respectively, and an effective no-op on Big Sur (until CLT 13 inevitably breaks things again, in which case this shim will fix it).

[MikeMcQuaid]

We mandate the CLT on older OS versions, and you indeed will need the CLT to get the correct SDK.

Sorry, I mean: is this still an issue on those older OS versions which don't have Xcode installed at all?

The shims will point system Ruby to /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk and /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk for Mojave and Catalina respectively, and an effective no-op on Big Sur (until CLT 13 inevitably breaks things again, in which case this shim will fix it).

👍🏻

[Bo98]

is this still an issue on those older OS versions which don't have Xcode installed at all?

Ah yes, it depends on xcode-select -p. I've updated my previous comment on that. It's a problem either way.

[BrewTestBot]

Review period ended.

[Bo98]

The previous behaviour, to my knowledge, is not supported? I hope no one relied on being able to invoke a shim outside of the brew environment.

[MikeMcQuaid]

Given that we were in our CI environment: I don't think we should break this. At least it'd be good to attempt to infer HOMEBREW_LIBRARY if it's not specified based on the shim location?

[Bo98]

Tricky because of the different directory levels. Probably would need to go through levels and search for a specific file/folder.

Note that any HOMEBREW_MACOS_VERSION_NUMERIC check in this file would have also not worked, and never has when called this way. So I'd need to cover that too if we want to support this.

[MikeMcQuaid]

Fine with me then. Can we try to produce a human-readable error when this isn't defined? Also, I reckon hold off until after 3.0.2 is tagged so we can get a bit of wider testing time with this before a new tag.

[MikeMcQuaid]

@Bo98 Good to 🚢 now if you are.