-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
Cherry pick "Fix post_install_workaround downgrading development targets" to 0.66-stable #32715
Cherry pick "Fix post_install_workaround downgrading development targets" to 0.66-stable #32715
Conversation
Summary: The `__apply_Xcode_12_5_M1_post_install_workaround` script changes the `IPHONEOS_DEPLOYMENT_TARGET` to `11.0` for all pods. This causes problems if the pods were targetting `12.0` or higher. Many expo modules are targetting `12.0`. I fixed this issue by checking the existing version and only bumping the target if it is lower than `11.0`. See also: this discussion post by mikehardy reactwg/react-native-releases#1 (comment) <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [iOS] [Fixed] - __apply_Xcode_12_5_M1_post_install_workaround causing pods targetting iOS 12 and above to fail Pull Request resolved: #32633 Test Plan: 1. pick an iOS Pod that has a minimum deployment target of iOS 12 or higher, I chose the Braintree package 2. `npx react-native init myrnapp` 3. Open `ios/Podfile` and add the pod as a dependency: `pod 'Braintree', '~> 5'` (and upgrade the Podfile target to 12 (`platform :ios, '12.0'`)) 4. Compile the app. Before applying this patch: ❌ Build fails because Braintree uses iOS 12 features and was downgraded to target 11.0 After applying this patch: ✅ Build succeeds Reviewed By: fkgozali Differential Revision: D32638171 Pulled By: philIip fbshipit-source-id: 0487647583057f3cfefcf515820855c7d4b16d31
|
Base commit: bba5e6b |
Base commit: bba5e6b |
Not sure of the process but I think the release management folks just command line these @lunaleaps ? |
@mikehardy I'm looking to change the process so the work is placed on the pick requester -- really the "work" here is figuring out merge conflicts and also triggering our CircleCI tests. Granted, our CircleCI tests don't really provide much coverage yet but I think building the habit won't hurt. |
Summary: When trying to bring react-native-macos up to date with 0.66, I was running into an issue getting RNTester to compile due to an error regarding redefining `clockid_t`. Other people have been seeing similar issues as per [these search results](https://github.com/facebook/folly/issues?q=clockid_t). The history behind this appears to be as follows: Several declarations in `<time.h>` were not available on Apple platforms until macOS 10.12 and iOS 10, which is why Folly needs to check the minimum version and set `FOLLY_HAVE_CLOCK_GETTIME` as needed. The problem is, the current logic as it stands right now is to set `FOLLY_HAVE_CLOCK_GETTIME = 1` (which implies that we don't need to declare them ourselves as the OS provides them for us) if... * ...we're building for macOS, and the minimum required version is less than 10.12, or... * ...we're building for iOS, and the minimum required version is less than 10. However, this doesn't make any sense. This is saying that we don't need to declare these missing APIs if we could be compiling Folly for use on an older version (i.e., macOS 10.11/iOS 9 or earlier), which is totally wrong! Instead, we ought to be checking if the versions are *at least* macOS 10.12 or iOS 10. React Native currently works around this by eliminating the minimum version check entirely with [this PR](facebook/react-native#32715), which is certainly a valid local fix ([the minimum iOS version for React Native apps is currently iOS 11](https://github.com/facebook/react-native/blob/1b31d6bb582768ccbe92d3c1a9e43354a8c531e5/template/ios/Podfile#L4)), but doesn't solve the problem at its core. This PR does solve the problem. I have not tested building this with a minimum version below the above thresholds for use on a modern version of macOS/iOS, but considering the discussion in #1545, I think we should be safe to ignore these older versions from now on. Pull Request resolved: #1688 Reviewed By: yfeldblum Differential Revision: D33483705 Pulled By: Orvid fbshipit-source-id: 0fe7c556af7e5b79a7679f75d003cf81a8f412ce
Summary
ℹ️ This is a cherry-pick of #32633 to
0.66-stable
The
__apply_Xcode_12_5_M1_post_install_workaround
script changes theIPHONEOS_DEPLOYMENT_TARGET
to11.0
for all pods. This causes problems if the pods were targetting12.0
or higher. Many expo modules are targetting12.0
.I fixed this issue by checking the existing version and only bumping the target if it is lower than
11.0
.See also: this discussion post by @mikehardy reactwg/react-native-releases#1 (comment)
Changelog
[iOS] [Fixed] - __apply_Xcode_12_5_M1_post_install_workaround causing pods targetting iOS 12 and above to fail
Test Plan
Test (failing before this patch, passing after this patch)
npx react-native init myrnapp
ios/Podfile
and add the pod as a dependency:pod 'Braintree', '~> 5'
(and upgrade the Podfile target to 12 (platform :ios, '12.0'
))Before applying this patch: ❌ Build fails because Braintree uses iOS 12 features and was downgraded to target 11.0
After applying this patch: ✅ Build succeeds