Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: SDKROOT build setting, interpolated when under CARTHAGE to set macosx, otherwise set iphoneos — allowing Xcode’s GUI to show Mac Catalyst destination #491

Merged
merged 1 commit into from
May 5, 2020

Conversation

jdhealy
Copy link
Contributor

@jdhealy jdhealy commented May 5, 2020

fix: SDKROOT build setting, interpolated when under CARTHAGE to set macosx, otherwise set iphoneos — allowing Xcode’s GUI to show Mac Catalyst destination.

Because of an xcodebuild bug involving the sdk flag and implicit dependency, Carthage is forced into a reliance (based on Xcode’s default) on SDKROOT as default or explicitly set to macosx (or equivalent) under the ‘single target, multiple platform’ paradigm.

xcodebuild itself has weird behavior: you’d see — as of commit «99f51f3» — xcodebuild archive --showBuildSettings --skipUnavailableActions -project Sentry.xcodeproj -scheme Sentry will no longer display the same macosx-SDKROOT–based build settings that xcodebuild archive Sentry.xcodeproj builds with (even when -destination 'generic/platform=macOS' is suffixed on at the end.)

This commit gets carthage building sentry-cocoa without the hangups above by switching over the CARTHAGE build setting value (or absence) to acquire the SDKROOT build setting value.

…and a couple notes on SUPPORTED_PLATFORMS. 👍

…et `macosx`, otherwise set `iphoneos` — allowing Xcode·s GUI to show Mac Catalyst destinations.

Of minor note is the unfortunate reality that — as of commit «99f51f3» — `xcodebuild archive --showBuildSettings --skipUnavailableActions -project Sentry·xcodeproj -scheme Sentry` will no longer display the same `macosx`-`SDKROOT`–based build settings that `xcodebuild archive Sentry·xcodeproj` builds with (even when `-destination 'generic/platform=macOS'` is suffixed on at the end.)

More pressing note: `SUPPORTED_PLATFORMS` in service of ‘single target, multiple platform’ extrapolation has some restrictions — but, not especially burdensome.

And one unfortunate shortcoming of `SUPPORTED_PLATFORMS` future potential under Carthage gets denoted.
// engage in dollar-parentheses syntax — unless that dollar-parentheses basis is
// entirely non-platform–derived, e.g. based upon `XCODE_VERSION_MAJOR`.
// Note: Carthage, unfortunately, as current of v0.34.0 queries rather harshly on the platform values below
// ⋯ quite early in the process, queried values not compiled into Carthage will cause hard errors.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, all the platforms listed right now are accommodated by Carthage, but future ones — under the behavior that’s current as of v0.34.0 — would hard error fairly early in the carthage run.

Copy link
Member

@HazAT HazAT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome PR, thank you very much.
I was trying to make this work correctly but this solution solves it perfectly.
Will update our builds to correctly build Carthage again.
❤️ ❤️ ❤️

@HazAT HazAT merged commit 3fa1186 into getsentry:master May 5, 2020
@philipphofmann
Copy link
Member

Thanks @jdhealy for the help 👏

philipphofmann added a commit that referenced this pull request Jan 29, 2024
Fix Sources/Configuration/SDK.xcconfig by removing the workaround added with #491 so CI can build Carthage XCFrameworks to include VisionOS. The workaround seems to be fixed with Carthage/Carthage#3001 in Carthage 0.35.0 released in Jun 2020. Therefore, we can remove the SDKROOT__CARTHAGE settings in Sources/Configuration/SDK.xcconfig, which caused problems when building the SDK for visionOS see #3410 (comment). We never removed the workaround #491, as it didn't cause any problems.

Furthermore, bump pre-commit action https://github.com/python-jsonschema/check-jsonschema to 0.27.3, so it allows macos-13-xlarge as a valid runner.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants