react-native-macos/scripts/react_native_pods.rb

335 строки
16 KiB
Ruby
Исходник Обычный вид История

# Copyright (c) Meta Platforms, Inc. and affiliates.
#
# This source code is licensed under the MIT license found in the
# LICENSE file in the root directory of this source tree.
require 'json'
Fix `pod install --project-directory=ios` failing when Hermes is enabled (#33909) Summary: `pod install --project-directory=ios` silently fails to prep Hermes: ``` % pod install --project-directory=ios [Codegen] Generating ios/build/generated/ios/React-Codegen.podspec.json [Hermes] Downloading Hermes source code for commit 515e112edc267ad58d3c70991b3d9a721cc66b19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 9478k 0 9478k 0 0 3939k 0 --:--:-- 0:00:02 --:--:-- 5591k [Hermes] Expanding Hermes tarball for commit 515e112edc267ad58d3c70991b3d9a721cc66b19 [Hermes] Using pre-built HermesC [!] One or more resources were not found and will not be included in the project. If they are found later and you want to include them, run `pod install` again. warn Multiple Podfiles were found: ios/Podfile,macos/Podfile. Choosing ios/Podfile automatically. If you would like to select a different one, you can configure it via "project.ios.sourceDir". You can learn more about it here: https://github.com/react-native-community/cli/blob/master/docs/configuration.md Auto-linking React Native module for target `ReactTestApp`: ReactTestApp-DevSupport Analyzing dependencies Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec` [Codegen] Found FBReactNativeSpec Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec` Fetching podspec for `boost` from `../node_modules/react-native/third-party-podspecs/boost.podspec` Fetching podspec for `glog` from `../node_modules/react-native/third-party-podspecs/glog.podspec` [!] No podspec found for `hermes-engine` in `../node_modules/react-native/sdks/hermes/hermes-engine.podspec` % ls -l node_modules/react-native/sdks total 0 hermes-engine hermesc ``` ## Changelog [iOS] [Fixed] - `pod install --project-directory=ios` fails when Hermes is enabled Pull Request resolved: https://github.com/facebook/react-native/pull/33909 Test Plan: Instead of running `pod install` inside `ios` folder, run `pod install --project-directory=ios`. Reviewed By: cortinico Differential Revision: D36693625 Pulled By: hramos fbshipit-source-id: 8757a9c388348276b07c785c211979ec8f2e2f84
2022-05-26 20:07:57 +03:00
require 'open3'
require 'pathname'
require_relative './react_native_pods_utils/script_phases.rb'
require_relative './cocoapods/hermes.rb'
require_relative './cocoapods/flipper.rb'
require_relative './cocoapods/fabric.rb'
require_relative './cocoapods/codegen.rb'
require_relative './cocoapods/codegen_utils.rb'
require_relative './cocoapods/utils.rb'
require_relative './cocoapods/new_architecture.rb'
require_relative './cocoapods/local_podspec_patch.rb'
$CODEGEN_OUTPUT_DIR = 'build/generated/ios'
$CODEGEN_COMPONENT_DIR = 'react/renderer/components'
$CODEGEN_MODULE_DIR = '.'
$FOLLY_VERSION = '2021.07.22.00'
$START_TIME = Time.now.to_i
# This function returns the min iOS version supported by React Native
# By using this function, you won't have to manualy change your Podfile
# when we change the minimum version supported by the framework.
def min_ios_version_supported
return '12.4'
end
# This function prepares the project for React Native, before processing
# all the target exposed by the framework.
def prepare_react_native_project!
# Temporary solution to suppress duplicated GUID error.
# Can be removed once we move to generate files outside pod install.
install! 'cocoapods', :deterministic_uuids => false
ReactNativePodsUtils.create_xcode_env_if_missing
end
# Function that setup all the react native dependencies
# 
# Parameters
# - path: path to react_native installation.
# - fabric_enabled: whether fabric should be enabled or not.
# - new_arch_enabled: whether the new architecture should be enabled or not.
# - production: whether the dependencies must be installed to target a Debug or a Release build.
# - hermes_enabled: whether Hermes should be enabled or not.
# - flipper_configuration: The configuration to use for flipper.
# - app_path: path to the React Native app. Required by the New Architecture.
# - config_file_dir: directory of the `package.json` file, required by the New Architecture.
def use_react_native! (
path: "../node_modules/react-native",
fabric_enabled: false,
new_arch_enabled: ENV['RCT_NEW_ARCH_ENABLED'] == '1',
production: ENV['PRODUCTION'] == '1',
hermes_enabled: ENV['USE_HERMES'] && ENV['USE_HERMES'] == '0' ? false : true,
flipper_configuration: FlipperConfiguration.disabled,
app_path: '..',
config_file_dir: '')
CodegenUtils.clean_up_build_folder(app_path, $CODEGEN_OUTPUT_DIR)
# We are relying on this flag also in third parties libraries to proper install dependencies.
# Better to rely and enable this environment flag if the new architecture is turned on using flags.
ENV['RCT_NEW_ARCH_ENABLED'] = new_arch_enabled ? "1" : "0"
fabric_enabled = fabric_enabled || new_arch_enabled
prefix = path
ReactNativePodsUtils.warn_if_not_on_arm64()
# The Pods which should be included in all projects
pod 'FBLazyVector', :path => "#{prefix}/Libraries/FBLazyVector"
Make codegen more reliable on iOS (#30792) Summary: This addesses a few issues I noticed while migrating my app to the new build-time codegen on iOS. 1. I noticed random failures because of codegen on iOS. This is mostly due to the fact the codegen output files are not specified in the xcode script. The only reason it works relatively fine currently is because the codegen output is inside the input files directory. This has the side effect of causing files to be regenerated every build, then causes all core modules to be recompiled which adds up a significant amount of time to rebuilds. To fix this I added the generated files to the script phase output and moved the FBReactNativeSpec dir outside of the codegen source (Libraries). I moved it to the React directory as this seemed to make sense and is where a lot of iOS files are as well as the core modules. Note this might require internal changes. This removes the circular dependency between our build phase input and output so consecutive builds can be cached properly. 2. Add `set -o pipefail` to the xcode script, this helped propagate errors properly to xcode because of the `| tee` pipe so it fails at the script phase and not later with a header not found error. Also add `2>&1` to pipe stderr to stdout so errors are also captured in the log file. 3. Add the `-l` flag to the bash invocation to help finding the yarn binary. With my setup yarn is added to the system PATH in my user .profile. Adding this file will cause bash to source the user environment which xcode scripts does not by default. I think this will help with most setups. 4. If yarn is not found the `command -v yarn` would make the script exit without any output because of the -e flag. I made a change to ignore the return code and check later if YARN_BINARY is set and have an explicit error message if not. ## Changelog [iOS] [Fixed] - Make codegen more reliable on iOS Pull Request resolved: https://github.com/facebook/react-native/pull/30792 Test Plan: Tested various project states to make sure the build always succeeds in RN tester: - Simulate fresh clone, remove all ignored files, install pods, build - Build, delete FBReactNativeSpec generated files, build again - Build, build again, make sure FBReactNativeSpec is cached and not rebuilt - Make the script fail and check that xcode shows the script error logs properly ![image](https://user-images.githubusercontent.com/2677334/105891571-c8badd00-5fde-11eb-839c-259d8e448523.png) Note: Did not test fabric Reviewed By: fkgozali Differential Revision: D26104213 Pulled By: hramos fbshipit-source-id: e18d9a0b9ada7c0c2e608d29ffe88087f04605b4
2021-02-02 01:36:52 +03:00
pod 'FBReactNativeSpec', :path => "#{prefix}/React/FBReactNativeSpec"
pod 'RCTRequired', :path => "#{prefix}/Libraries/RCTRequired"
Fix using Swift in a native module with Fabric enabled (#33743) Summary: Using Fabric with a Swift native module is currently broken. There are currently two issues. If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`. Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name. ## Changelog <!-- 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] - Fix using Swift in a native module with Fabric enabled Pull Request resolved: https://github.com/facebook/react-native/pull/33743 Test Plan: 1. Clone [this](https://github.com/fortmarek/react-native) repo 2. From `main`, apply changes from [this](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58) commit (adding Swift file to the `MyNativeView` native module in the RN tester app) 3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester` 4. Observe errors 5. Apply [the commit](https://github.com/facebook/react-native/commit/9772c6209d73257f679b76407e1b5a27ffe03219) from this PR 6. Both pod install and the subsequent build should succeed. I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main` Reviewed By: dmitryrykun Differential Revision: D36097852 Pulled By: cipolleschi fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
2022-05-04 14:31:23 +03:00
pod 'RCTTypeSafety', :path => "#{prefix}/Libraries/TypeSafety", :modular_headers => true
pod 'React', :path => "#{prefix}/"
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
pod 'React-Core', :path => "#{prefix}/"
pod 'React-CoreModules', :path => "#{prefix}/React/CoreModules"
pod 'React-RCTAppDelegate', :path => "#{prefix}/Libraries/AppDelegate"
pod 'React-RCTActionSheet', :path => "#{prefix}/Libraries/ActionSheetIOS"
pod 'React-RCTAnimation', :path => "#{prefix}/Libraries/NativeAnimation"
pod 'React-RCTBlob', :path => "#{prefix}/Libraries/Blob"
pod 'React-RCTImage', :path => "#{prefix}/Libraries/Image"
pod 'React-RCTLinking', :path => "#{prefix}/Libraries/LinkingIOS"
pod 'React-RCTNetwork', :path => "#{prefix}/Libraries/Network"
pod 'React-RCTSettings', :path => "#{prefix}/Libraries/Settings"
pod 'React-RCTText', :path => "#{prefix}/Libraries/Text"
pod 'React-RCTVibration', :path => "#{prefix}/Libraries/Vibration"
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
pod 'React-Core/RCTWebSocket', :path => "#{prefix}/"
pod 'React-bridging', :path => "#{prefix}/ReactCommon"
pod 'React-cxxreact', :path => "#{prefix}/ReactCommon/cxxreact"
pod 'React-jsi', :path => "#{prefix}/ReactCommon/jsi"
pod 'React-jsiexecutor', :path => "#{prefix}/ReactCommon/jsiexecutor"
pod 'React-jsinspector', :path => "#{prefix}/ReactCommon/jsinspector"
Get CallInvokers from the bridge Summary: ## Context For now, assume TurboModules doesn't exist. **What happens when we call an async NativeModule method?** Everytime JS calls an async NativeModule method, we don't immediately execute it. The legacy infra pushes the call into some queue managed by `MessageQueue.js`. This queue is "flushed" or "emptied" by the following events: - **Flushed:** A C++ -> JS call. NativeModule async methods can called with an `onSuccess` and/or `onFail` callback(s). Calling `NativeToJsBridge::invokeCallback` to invoke one of these callbacks is one way for ObjC++/C++/Java to call into JS. Another way is via JSModule method calls, which are initiated by `NativeToJsBridge::callFunction`. - **Flushed:** When `JSIExecutor::flush` is called. Since TurboModules don't exist, this only happens when we call `JSIExecutor::loadApplicationScript`. - **Emptied:** When more than 5 ms have passed, and the queue hasn't been flushed/emptied, on the next async NativeModule method call, we add to the queue. Afterwards, we empty it, and invoke all the NativeModule method calls. **So, what's the difference between flushed and emptied?** > Note: These are two terms I just made up, but the distinction is important. If the queue was "flushed", and it contained at least one NativeModule method call, `JsToNativeBridge` dispatches the `onBatchComplete` event. On Android, the UIManager module is the only module that listens to this event. This `onBatchComplete` event doesn't fire if the queue was "emptied". **Why does any of this matter?** 1. TurboModules exist. 2. We need the TurboModules infra to have `JsToNativeBridge` dispatch `onBatchComplete`, which depends on: - **Problem 1:** The queue being flushed on calls into JS from Java/C++/ObjC++. - **Problem 2:** There being queued up NativeModule async method calls when the queue is flushed. In D14656466, fkgozali fixed Problem 1 by making every C++/Java/Obj -> JS call from TurboModules also execute `JSIExecutor::flush()`. This means that, with TurboModules, we flush the NativeModule async method call queue as often as we do without TurboModules. So far, so good. However, we still have one big problem: As we convert more NativeModules to TurboModules, the average size of the queue of NativeModule method calls will become smaller and smaller, because more NativeModule method calls will be TurboModule method calls. This queue will more often be empty than not. Therefore, we'll end up dispatching the `onBatchComplete` event less often with TurboModules enabled. So, somehow, when we're about to flush the NativeModule method call queue, we need `JsToNativeBridge` to understand that we've executed TurboModule method calls in the batch. These calls would have normally been queued, which would have led the queue size to be non-zero. So if, during a batch, some TurboModule async method calls were executed, `JsToNativeBridge` should dispatch `onBatchComplete`. **So, what does this diff do?** 1. Make `Instance` responsible for creating the JS `CallInvoker`. 2. Make `NativeToJsBridge` responsible for creating the native `CallInvoker`. `Instance` calls into `NativeToJsBridge` to get the native `CallInvoker`. 3. Hook up `CatalystInstanceImpl`, the Android bridge, with the new JS `CallInvoker`, and the new native `CallInvoker`. This fixes `onBatchComplete` on Android. iOS work is pending. Changelog: [Android][Fixed] - Ensure `onBatchComplete` is dispatched correctly with TurboModules Reviewed By: mdvacca Differential Revision: D20717931 fbshipit-source-id: bc3ccbd6c135b7f084edbc6ddb4d1e3c0c7e0875
2020-04-01 21:36:50 +03:00
pod 'React-callinvoker', :path => "#{prefix}/ReactCommon/callinvoker"
pod 'React-runtimeexecutor', :path => "#{prefix}/ReactCommon/runtimeexecutor"
Rename <ReactCommon/NativeModulePerfLogger.h> to <reactperflogger/NativeModulePerfLogger.h> Summary: ## Motivation This rename will fix the following CircleCI build failures: - [test_ios_unit_frameworks](https://circleci.com/gh/facebook/react-native/150473?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link) - [test_ios_detox_frameworks](https://circleci.com/gh/facebook/react-native/150474?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link) ## Investigation We have 4 podspec targets that map to the same header namespace (i.e: `header_dir`) `ReactCommon`: - **New:** `React-perflogger`: Directory is `ReactCommon/preflogger`, and contains `NativeModulePerfLogger.{h,cpp}`. - `React-runtimeexecutor`: Directory is `ReactCommon/runtimeexecutor`, and contains only `RuntimeExecutor.h` - `React-callinvoker`: Directory is `ReactCommon/callinvoker`, and contains only `CallInvoker.h` - `ReactCommon/turbomodule/core`: Directory is `ReactCommon/turbomodule`, and contains C++ files, as well has header files. **The problem:** We couldn't import headers from `React-perflogger` in `ReactCommon/turbomodule/core` files. **The cause:** I'm not entirely sure why, but I was able to discern the following two rules by playing around with the podspecs: 1. If your podspec target has a cpp file, it'll generate a framework when `USE_FRAMEWORKS=1`. 2. Two different frameworks cannot map to the same `module_name` or `header_dir`. (Why? No clue. But something breaks silently when this is the case). So, this is what happened when I landed `React-perflogger` (D21443610): 1. The TurboModules code generates the `ReactCommon` framework that uses the `ReactCommon` header namespace. 2. `React-runtimeexecutor` and `React-callinvoker` also used the `ReactCommon` header namespace. However, neither generate a framework because of Rule 1. 3. When I comitted `React-perflogger`, I introduced a second framework that competed with the `ReactCommon` framework (i.e: TurboModules code) for the `ReactCommon` header namespace. Rule 2 violation. ## Thoughts on renaming - `<perflogger/NativeModulePerfLogger.h>` is too generic, and the `perflogger` namepsace is used internally within FB. - `<react/perflogger/NativeModulePerfLogger.h>` matches our fabric header format, but I'm pretty sure that slashes aren't allowed in `header_dir`: I tested this and it didn't work. IIRC, only alphanumeric and underscore are valid characters for `header_dir` or `module_name`. So, I opted to just use `reactperflogger`. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D21598852 fbshipit-source-id: 60da5d0f7758eaf13907a080b7d8756688f40723
2020-05-16 01:21:25 +03:00
pod 'React-perflogger', :path => "#{prefix}/ReactCommon/reactperflogger"
pod 'React-logger', :path => "#{prefix}/ReactCommon/logger"
Fix using Swift in a native module with Fabric enabled (#33743) Summary: Using Fabric with a Swift native module is currently broken. There are currently two issues. If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`. Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name. ## Changelog <!-- 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] - Fix using Swift in a native module with Fabric enabled Pull Request resolved: https://github.com/facebook/react-native/pull/33743 Test Plan: 1. Clone [this](https://github.com/fortmarek/react-native) repo 2. From `main`, apply changes from [this](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58) commit (adding Swift file to the `MyNativeView` native module in the RN tester app) 3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester` 4. Observe errors 5. Apply [the commit](https://github.com/facebook/react-native/commit/9772c6209d73257f679b76407e1b5a27ffe03219) from this PR 6. Both pod install and the subsequent build should succeed. I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main` Reviewed By: dmitryrykun Differential Revision: D36097852 Pulled By: cipolleschi fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
2022-05-04 14:31:23 +03:00
pod 'ReactCommon/turbomodule/core', :path => "#{prefix}/ReactCommon", :modular_headers => true
pod 'Yoga', :path => "#{prefix}/ReactCommon/yoga", :modular_headers => true
pod 'DoubleConversion', :podspec => "#{prefix}/third-party-podspecs/DoubleConversion.podspec"
pod 'glog', :podspec => "#{prefix}/third-party-podspecs/glog.podspec"
pod 'boost', :podspec => "#{prefix}/third-party-podspecs/boost.podspec"
Fix using Swift in a native module with Fabric enabled (#33743) Summary: Using Fabric with a Swift native module is currently broken. There are currently two issues. If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`. Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name. ## Changelog <!-- 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] - Fix using Swift in a native module with Fabric enabled Pull Request resolved: https://github.com/facebook/react-native/pull/33743 Test Plan: 1. Clone [this](https://github.com/fortmarek/react-native) repo 2. From `main`, apply changes from [this](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58) commit (adding Swift file to the `MyNativeView` native module in the RN tester app) 3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester` 4. Observe errors 5. Apply [the commit](https://github.com/facebook/react-native/commit/9772c6209d73257f679b76407e1b5a27ffe03219) from this PR 6. Both pod install and the subsequent build should succeed. I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main` Reviewed By: dmitryrykun Differential Revision: D36097852 Pulled By: cipolleschi fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
2022-05-04 14:31:23 +03:00
pod 'RCT-Folly', :podspec => "#{prefix}/third-party-podspecs/RCT-Folly.podspec", :modular_headers => true
run_codegen!(
app_path,
config_file_dir,
:new_arch_enabled => new_arch_enabled,
:disable_codegen => ENV['DISABLE_CODEGEN'] == '1',
:react_native_path => prefix,
:fabric_enabled => fabric_enabled,
:codegen_output_dir => $CODEGEN_OUTPUT_DIR,
:package_json_file => File.join(__dir__, "..", "package.json"),
:folly_version => $FOLLY_VERSION
)
Fix using Swift in a native module with Fabric enabled (#33743) Summary: Using Fabric with a Swift native module is currently broken. There are currently two issues. If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`. Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name. ## Changelog <!-- 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] - Fix using Swift in a native module with Fabric enabled Pull Request resolved: https://github.com/facebook/react-native/pull/33743 Test Plan: 1. Clone [this](https://github.com/fortmarek/react-native) repo 2. From `main`, apply changes from [this](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58) commit (adding Swift file to the `MyNativeView` native module in the RN tester app) 3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester` 4. Observe errors 5. Apply [the commit](https://github.com/facebook/react-native/commit/9772c6209d73257f679b76407e1b5a27ffe03219) from this PR 6. Both pod install and the subsequent build should succeed. I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main` Reviewed By: dmitryrykun Differential Revision: D36097852 Pulled By: cipolleschi fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
2022-05-04 14:31:23 +03:00
pod 'React-Codegen', :path => $CODEGEN_OUTPUT_DIR, :modular_headers => true
if fabric_enabled
checkAndGenerateEmptyThirdPartyProvider!(prefix, new_arch_enabled, $CODEGEN_OUTPUT_DIR)
setup_fabric!(prefix)
Upstream RN macOS Hermes integration bits (#29748) Summary: Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with. As to the actual changes, these include: * Sharing Android’s Hermes executor with the objc side of the codebase. * Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`). * Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps… * …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too. All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods. ## Changelog [General] [Added] - Upstream RN macOS Hermes integration bits Pull Request resolved: https://github.com/facebook/react-native/pull/29748 Test Plan: Building RNTester for iOS and Android still works as before. To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`: <img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png"> Reviewed By: TheSavior Differential Revision: D23304618 Pulled By: fkgozali fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
2020-08-27 11:16:30 +03:00
end
install_hermes_if_enabled(hermes_enabled, prefix)
Automatic update of `RCT-Folly` (#32659) Summary: When upgrading `react-native`, the version `RCT-Folly` defined [here](https://github.com/facebook/react-native/blob/main/third-party-podspecs/RCT-Folly.podspec) can change. If that happens, if you run `pod install` after `yarn install`, you will get a similar error to this: ``` [!] CocoaPods could not find compatible versions for pod "RCT-Folly": In snapshot (Podfile.lock): RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`) In Podfile: RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`) React-RCTNetwork (from `../node_modules/react-native/Libraries/Network`) was resolved to 0.66.3, which depends on RCT-Folly (= 2021.06.28.00-v2) ``` This error occurs because `Cocoapods` does not update pods that point to a local podspec. Locally, you could resolve this issue by running `pod update RCT-Folly --no-repo-update`. On the CI, you have to do a clean checkout (in case you cache the `Pods` folder which we do). All of this makes upgrading `react-native` painful - for the whole community and for us shopify There are other users who have struggled with this, such as [here](https://github.com/facebook/react-native/issues/32423). The suggestion there is to delete `Podfile.lock` which is unnecessary - but it shows that users are confused what to do with this error and is something worth fixing. To mitigate these issues, `react_native_pods.rb` automatically marks `RCT-Folly` as changed in the [detect_changes_with_podfile method](https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/lockfile.rb#L289) from `Pod::Lockfile` if the version in `node_modules/react-native/third-party-podspecs/RCT-Folly.podspec` and `Pods/Local Podspecs/RCT-Folly.podspec.json` mismatch. Instead of automatically updating the local podspec (in `Pods/Local Podspecs` directory) we could also: a) integrate `RCT-Folly` as a local pod (such as `React-Core` and others) b) integrate `RCT-Folly` as an external dependency (going through Cocoapods' centralized repository) I don't have enough context on why `RCT-Folly` is bundled the way it is, so I am open to suggestions here. ## Changelog <!-- 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] - Fix `pod install` when `RCT-Folly` version has been updated. Pull Request resolved: https://github.com/facebook/react-native/pull/32659 Test Plan: I have created a [repository](https://github.com/fortmarek/react-native-upgrade-reproduction) where you can reproduce the issue. You can simply: 1) clone the repo (`git clone https://github.com/fortmarek/react-native-upgrade-reproduction`) 2) Run `yarn install && cd ios && pod install` 3) Change `react-native` version in `package.json` to `0.66.3` 4) Run again `yarn install && pod install` 5) Observe error To test the fix, you can then: 1) copy-paste the `react_native_pods.rb` file from this branch to `react-native-upgrade-reproduction/node_modules/scripts/react_native_pods.rb` 2) run `pod install` again This time, the `pod install` command should succeed. Reviewed By: sota000 Differential Revision: D32720758 Pulled By: cortinico fbshipit-source-id: 940db9c9f0530f896e47b676dec46bc93cea0085
2022-03-17 13:52:57 +03:00
# CocoaPods `configurations` option ensures that the target is copied only for the specified configurations,
# but those dependencies are still built.
# Flipper doesn't currently compile for release https://github.com/facebook/react-native/issues/33764
# Setting the production flag to true when build for production make sure that we don't install Flipper in the app in the first place.
if flipper_configuration.flipper_enabled && !production
install_flipper_dependencies(prefix)
use_flipper_pods(flipper_configuration.versions, :configurations => flipper_configuration.configurations)
end
pods_to_update = LocalPodspecPatch.pods_to_update(:react_native_path => prefix)
Automatic update of `RCT-Folly` (#32659) Summary: When upgrading `react-native`, the version `RCT-Folly` defined [here](https://github.com/facebook/react-native/blob/main/third-party-podspecs/RCT-Folly.podspec) can change. If that happens, if you run `pod install` after `yarn install`, you will get a similar error to this: ``` [!] CocoaPods could not find compatible versions for pod "RCT-Folly": In snapshot (Podfile.lock): RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`) In Podfile: RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`) React-RCTNetwork (from `../node_modules/react-native/Libraries/Network`) was resolved to 0.66.3, which depends on RCT-Folly (= 2021.06.28.00-v2) ``` This error occurs because `Cocoapods` does not update pods that point to a local podspec. Locally, you could resolve this issue by running `pod update RCT-Folly --no-repo-update`. On the CI, you have to do a clean checkout (in case you cache the `Pods` folder which we do). All of this makes upgrading `react-native` painful - for the whole community and for us shopify There are other users who have struggled with this, such as [here](https://github.com/facebook/react-native/issues/32423). The suggestion there is to delete `Podfile.lock` which is unnecessary - but it shows that users are confused what to do with this error and is something worth fixing. To mitigate these issues, `react_native_pods.rb` automatically marks `RCT-Folly` as changed in the [detect_changes_with_podfile method](https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/lockfile.rb#L289) from `Pod::Lockfile` if the version in `node_modules/react-native/third-party-podspecs/RCT-Folly.podspec` and `Pods/Local Podspecs/RCT-Folly.podspec.json` mismatch. Instead of automatically updating the local podspec (in `Pods/Local Podspecs` directory) we could also: a) integrate `RCT-Folly` as a local pod (such as `React-Core` and others) b) integrate `RCT-Folly` as an external dependency (going through Cocoapods' centralized repository) I don't have enough context on why `RCT-Folly` is bundled the way it is, so I am open to suggestions here. ## Changelog <!-- 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] - Fix `pod install` when `RCT-Folly` version has been updated. Pull Request resolved: https://github.com/facebook/react-native/pull/32659 Test Plan: I have created a [repository](https://github.com/fortmarek/react-native-upgrade-reproduction) where you can reproduce the issue. You can simply: 1) clone the repo (`git clone https://github.com/fortmarek/react-native-upgrade-reproduction`) 2) Run `yarn install && cd ios && pod install` 3) Change `react-native` version in `package.json` to `0.66.3` 4) Run again `yarn install && pod install` 5) Observe error To test the fix, you can then: 1) copy-paste the `react_native_pods.rb` file from this branch to `react-native-upgrade-reproduction/node_modules/scripts/react_native_pods.rb` 2) run `pod install` again This time, the `pod install` command should succeed. Reviewed By: sota000 Differential Revision: D32720758 Pulled By: cortinico fbshipit-source-id: 940db9c9f0530f896e47b676dec46bc93cea0085
2022-03-17 13:52:57 +03:00
if !pods_to_update.empty?
if Pod::Lockfile.public_instance_methods.include?(:detect_changes_with_podfile)
Pod::Lockfile.prepend(LocalPodspecPatch)
else
Pod::UI.warn "Automatically updating #{pods_to_update.join(", ")} has failed, please run `pod update #{pods_to_update.join(" ")} --no-repo-update` manually to fix the issue."
end
end
end
# Getter to retrieve the folly flags in case contributors need to apply them manually.
#
# Returns: the folly compiler flags
def folly_flags()
return NewArchitectureHelper.folly_compiler_flags
end
# This function can be used by library developer to prepare their modules for the New Architecture.
# It passes the Folly Flags to the module, it configures the search path and installs some New Architecture specific dependencies.
#
# Parameters:
# - spec: The spec that has to be configured with the New Architecture code
# - new_arch_enabled: Whether the module should install dependencies for the new architecture
def install_modules_dependencies(spec, new_arch_enabled: ENV['RCT_NEW_ARCH_ENABLED'] == "1")
NewArchitectureHelper.install_modules_dependencies(spec, new_arch_enabled, $FOLLY_VERSION)
end
# It returns the default flags.
def get_default_flags()
return ReactNativePodsUtils.get_default_flags()
end
# It installs the flipper dependencies into the project.
#
# Parameters
# - versions: a dictionary of Flipper Library -> Versions that can be used to customize which version of Flipper to install.
# - configurations: an array of configuration where to install the dependencies.
Make flipper pods configurations configurable (#29074) Summary: This PR allows the use_flipper! helper function to be used in projects that have more than just Debug/Release configurations. For example, a project may have DevDebug, DevRelease, ProdDebug, and ProdRelease configurations. These projects can now do: ```ruby use_flipper!(configurations: ['DevDebug', 'ProdDebug']) ``` ## Changelog [iOS][Added] Ability to set which configuration to enable flipper for when using use_flipper! Pull Request resolved: https://github.com/facebook/react-native/pull/29074 Test Plan: I don't know how to run code in this repository, so I copy and pasted this function into the Podfile of an existing project. My complete Podfile is as below: ```ruby # Uncomment the next line to define a global platform for your project platform :ios, '10.0' require_relative '../node_modules/react-native-community/cli-platform-ios/native_modules' project 'marketplace', 'Dev.Debug' => :debug, 'Dev.Release' => :release, 'Prod.Debug' => :debug, 'Prod.Release' => :release def use_flipper!(versions = {}, configurations: ['Debug']) versions['Flipper'] ||= '~> 0.33.1' versions['DoubleConversion'] ||= '1.1.7' versions['Flipper-Folly'] ||= '~> 2.1' versions['Flipper-Glog'] ||= '0.3.6' versions['Flipper-PeerTalk'] ||= '~> 0.0.4' versions['Flipper-RSocket'] ||= '~> 1.0' pod 'FlipperKit', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitLayoutPlugin', versions['Flipper'], :configurations => configurations pod 'FlipperKit/SKIOSNetworkPlugin', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitUserDefaultsPlugin', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitReactPlugin', versions['Flipper'], :configurations => configurations # List all transitive dependencies for FlipperKit pods # to avoid them being linked in Release builds pod 'Flipper', versions['Flipper'], :configurations => configurations pod 'Flipper-DoubleConversion', versions['Flipper-DoubleConversion'], :configurations => configurations pod 'Flipper-Folly', versions['Flipper-Folly'], :configurations => configurations pod 'Flipper-Glog', versions['Flipper-Glog'], :configurations => configurations pod 'Flipper-PeerTalk', versions['Flipper-PeerTalk'], :configurations => configurations pod 'Flipper-RSocket', versions['Flipper-RSocket'], :configurations => configurations pod 'FlipperKit/Core', versions['Flipper'], :configurations => configurations pod 'FlipperKit/CppBridge', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FBCxxFollyDynamicConvert', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FBDefines', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FKPortForwarding', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitHighlightOverlay', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitLayoutTextSearchable', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitNetworkPlugin', versions['Flipper'], :configurations => configurations end # Post Install processing for Flipper def flipper_post_install(installer) installer.pods_project.targets.each do |target| if target.name == 'YogaKit' target.build_configurations.each do |config| config.build_settings['SWIFT_VERSION'] = '4.1' end end end end target 'marketplace' do # Comment the next line if you're not using Swift and don't want to use dynamic frameworks #use_frameworks! pod 'FBLazyVector', :path => '../node_modules/react-native/Libraries/FBLazyVector' pod 'FBReactNativeSpec', :path => '../node_modules/react-native/Libraries/FBReactNativeSpec' pod 'RCTRequired', :path => '../node_modules/react-native/Libraries/RCTRequired' pod 'RCTTypeSafety', :path => '../node_modules/react-native/Libraries/TypeSafety' pod 'React', :path => '../node_modules/react-native/' pod 'React-Core', :path => '../node_modules/react-native/' pod 'React-CoreModules', :path => '../node_modules/react-native/React/CoreModules' pod 'React-Core/DevSupport', :path => '../node_modules/react-native/' pod 'React-RCTActionSheet', :path => '../node_modules/react-native/Libraries/ActionSheetIOS' pod 'React-RCTAnimation', :path => '../node_modules/react-native/Libraries/NativeAnimation' pod 'React-RCTBlob', :path => '../node_modules/react-native/Libraries/Blob' pod 'React-RCTImage', :path => '../node_modules/react-native/Libraries/Image' pod 'React-RCTLinking', :path => '../node_modules/react-native/Libraries/LinkingIOS' pod 'React-RCTNetwork', :path => '../node_modules/react-native/Libraries/Network' pod 'React-RCTSettings', :path => '../node_modules/react-native/Libraries/Settings' pod 'React-RCTText', :path => '../node_modules/react-native/Libraries/Text' pod 'React-RCTVibration', :path => '../node_modules/react-native/Libraries/Vibration' pod 'React-Core/RCTWebSocket', :path => '../node_modules/react-native/' pod 'React-cxxreact', :path => '../node_modules/react-native/ReactCommon/cxxreact' pod 'React-jsi', :path => '../node_modules/react-native/ReactCommon/jsi' pod 'React-jsiexecutor', :path => '../node_modules/react-native/ReactCommon/jsiexecutor' pod 'React-jsinspector', :path => '../node_modules/react-native/ReactCommon/jsinspector' pod 'ReactCommon/callinvoker', :path => '../node_modules/react-native/ReactCommon' pod 'ReactCommon/turbomodule/core', :path => '../node_modules/react-native/ReactCommon' pod 'Yoga', :path => '../node_modules/react-native/ReactCommon/yoga', :modular_headers => true pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec' pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec' pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec' pod 'Intercom', '~> 6.0.0' pod 'RNDeviceInfo', :path => '../node_modules/react-native-device-info' pod 'react-native-netinfo', :podspec => '../node_modules/react-native-community/netinfo/react-native-netinfo.podspec' pod 'BugsnagReactNative', :podspec => '../node_modules/bugsnag-react-native/BugsnagReactNative.podspec' pod 'rn-fetch-blob', :podspec => '../node_modules/rn-fetch-blob/rn-fetch-blob.podspec' use_native_modules! pod 'react-native-intercom', :path => '../node_modules/react-native-intercom' pod 'react-native-image-resizer', :path => '../node_modules/react-native-image-resizer' pod 'RNVectorIcons', :path => '../node_modules/react-native-vector-icons' pod 'react-native-camera', :path => '../node_modules/react-native-camera' pod 'RNCPushNotificationIOS', :path => '../node_modules/react-native-community/push-notification-ios' pod 'RNDateTimePicker', :path => '../node_modules/react-native-community/datetimepicker' # Enables Flipper. # # Note that if you have use_frameworks! enabled, Flipper will not work and # you should disable these next few lines. use_flipper!(configurations: ['Dev.Debug', 'Prod.Debug']) post_install do |installer| flipper_post_install(installer) installer.pods_project.targets.each do |target| # The following is needed to ensure the "archive" step works in XCode. # It removes React & Yoga from the Pods project, as it is already included in the main project. # Without this, you'd see errors when you archive like: # "Multiple commands produce ... libReact.a" # "Multiple commands produce ... libyoga.a" targets_to_ignore = %w(React yoga) if targets_to_ignore.include? target.name target.remove_from_project end end end end ``` I then ran `pod install`: ``` nico:ios/ (dev*) $ pod install [20:14:43] Adding a custom script phase for Pod RNFBApp: [RNFB] Core Configuration Detected React Native module pods for BVLinearGradient, RNCAsyncStorage, RNCPicker, RNCPushNotificationIOS, RNDateTimePicker, RNFBApp, RNFBAuth, RNFBDatabase, RNFBDynamicLinks, RNFBFirestore, RNFBStorage, RNSVG, RNVectorIcons, ReactNativeNavigation, react-native-camera, react-native-cameraroll, react-native-config, react-native-flipper, react-native-get-random-values, react-native-image-resizer, and react-native-intercom Analyzing dependencies Downloading dependencies Generating Pods project Integrating client project Pod installation complete! There are 73 dependencies from the Podfile and 88 total pods installed. [!] use_native_modules! skipped the react-native dependency 'react-native-photo-view'. No podspec file was found. - Check to see if there is an updated version that contains the necessary podspec file - Contact the library maintainers or send them a PR to add a podspec. The react-native-webview podspec is a good example of a package.json driven podspec. See https://github.com/react-native-community/react-native-webview/blob/master/react-native-webview.podspec - If necessary, you can disable autolinking for the dependency and link it manually. See https://github.com/react-native-community/cli/blob/master/docs/autolinking.md#how-can-i-disable-autolinking-for-unsupported-library [!] use_native_modules! skipped the react-native dependency 'detox'. No podspec file was found. - Check to see if there is an updated version that contains the necessary podspec file - Contact the library maintainers or send them a PR to add a podspec. The react-native-webview podspec is a good example of a package.json driven podspec. See https://github.com/react-native-community/react-native-webview/blob/master/react-native-webview.podspec - If necessary, you can disable autolinking for the dependency and link it manually. See https://github.com/react-native-community/cli/blob/master/docs/autolinking.md#how-can-i-disable-autolinking-for-unsupported-library ``` Reviewed By: cpojer Differential Revision: D22795421 Pulled By: passy fbshipit-source-id: 89ba555eadc4918e9ac464a19a318198b237e01e
2020-07-29 12:43:17 +03:00
def use_flipper!(versions = {}, configurations: ['Debug'])
Pod::UI.warn "use_flipper is deprecated, use the flipper_configuration option in the use_react_native function"
use_flipper_pods(versions, :configurations => configurations)
end
# Function that executes after React Native has been installed to configure some flags and build settings.
#
# Parameters
# - installer: the Cocoapod object that allows to customize the project.
# - react_native_path: path to React Native.
# - mac_catalyst_enabled: whether we are running the Pod on a Mac Catalyst project or not.
def react_native_post_install(installer, react_native_path = "../node_modules/react-native", mac_catalyst_enabled: false)
ReactNativePodsUtils.apply_mac_catalyst_patches(installer) if mac_catalyst_enabled
if ReactNativePodsUtils.has_pod(installer, 'Flipper')
flipper_post_install(installer)
end
ReactNativePodsUtils.exclude_i386_architecture_while_using_hermes(installer)
ReactNativePodsUtils.fix_library_search_paths(installer)
ReactNativePodsUtils.fix_react_bridging_header_search_paths(installer)
ReactNativePodsUtils.set_node_modules_user_settings(installer, react_native_path)
NewArchitectureHelper.set_clang_cxx_language_standard_if_needed(installer)
is_new_arch_enabled = ENV['RCT_NEW_ARCH_ENABLED'] == "1"
NewArchitectureHelper.modify_flags_for_new_architecture(installer, is_new_arch_enabled)
Fix ios build error when podfile generate_multiple_pod_projects=true and fabric is on (#33381) Summary: there are build errors happened when in [`generate_multiple_pod_projects`](https://blog.cocoapods.org/CocoaPods-1.7.0-beta/#multiple-xcodeproj-generation) mode and fabric is on. since we have multiple pod projects, there are something breaks. ### `-DRCT_NEW_ARCH_ENABLED=1` does not pass to `RCTAppSetupUtils.mm` because `installer.pods_project` is targeting `Pods.xcodeproj` but not `React-Core.xcodeproj`. we should use ` installer.target_installation_results.pod_target_installation_results` to deal with `generate_multiple_pod_projects` mode. ### fatal error: 'CompactValue.h' file not found ``` In file included from /path/to/react-native/packages/rn-tester/build/generated/ios/react/renderer/components/rncore/Props.cpp:11: In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Codegen/react/renderer/components/rncore/Props.h:13: In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/ViewProps.h:11: In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/YogaStylableProps.h:10: /path/to/react-native/packages/rn-tester/Pods/Headers/Public/Yoga/yoga/YGStyle.h:16:10: fatal error: 'CompactValue.h' file not found #include "CompactValue.h" ^~~~~~~~~~~~~~~~ 1 error generated. ``` `Props.cpp` -> `YogaStylableProps.h` -> `YGStyle.h` -> `CompactValue.h` [`CompactValue.h` is internal private header for Yoga pod](https://github.com/facebook/react-native/blob/4eef075a583224ec9da6bbc4b42bc52508eb31be/ReactCommon/yoga/Yoga.podspec#L54-L56) where `React-Codegen` project cannot access to. ~there are some solutions toward this problem. one way is to make other yoga headers as public headers. i am not sure whether this solution would introduce any side effects. so i only make necessary projects to search yoga private headers.~ Update: a solution is to expose all yoga headers publicly. however, CocoaPods will put all public headers to module umbrella header. this will break YogaKit (swift) integration because swift module doesn't support c++. my pr is trying to expose all yoga headers to `$PODS_ROOT/Headers/Public/Yoga/yoga`, but use custom `module_map` to control which headers should be exposed to the swift module. CocoaPods's custom module_map has some limitation where cannot well support for both `use_frameworks!` mode and non use_frameworks! mode. there's a workaround to use `script_phase` copying the umbrella header to right place. ## Changelog [iOS] [Fixed] - Fix iOS build error when Podfile `generate_multiple_pod_projects=true` and Fabric is on Pull Request resolved: https://github.com/facebook/react-native/pull/33381 Test Plan: verify with rn-tester 1. add `generate_multiple_pod_projects` ```diff --- a/packages/rn-tester/Podfile +++ b/packages/rn-tester/Podfile @@ -5,7 +5,7 @@ platform :ios, '11.0' # Temporary solution to suppress duplicated GUID error. # Can be removed once we move to generate files outside pod install. -install! 'cocoapods', :deterministic_uuids => false +install! 'cocoapods', :generate_multiple_pod_projects => true, :deterministic_uuids => false USE_FRAMEWORKS = ENV['USE_FRAMEWORKS'] == '1' ``` 2. pod install and build rn-tester from xcode Reviewed By: cortinico Differential Revision: D34844041 Pulled By: dmitryrykun fbshipit-source-id: 93311b56d8e44491307a911ad58442f267c979eb
2022-04-11 16:04:20 +03:00
Pod::UI.puts "Pod install took #{Time.now.to_i - $START_TIME} [s] to run".green
end
# === LEGACY METHOD ===
# We need to keep this while we continue to support the old architecture.
# =====================
def use_react_native_codegen!(spec, options={})
return if ENV['RCT_NEW_ARCH_ENABLED'] == "1"
# TODO: Once the new codegen approach is ready for use, we should output a warning here to let folks know to migrate.
# The prefix to react-native
react_native_path = options[:react_native_path] ||= "../.."
# Library name (e.g. FBReactNativeSpec)
library_name = options[:library_name] ||= "#{spec.name.gsub('_','-').split('-').collect(&:capitalize).join}Spec"
Pod::UI.puts "[Codegen] Found #{library_name}"
relative_installation_root = Pod::Config.instance.installation_root.relative_path_from(Pathname.pwd)
output_dir = options[:output_dir] ||= $CODEGEN_OUTPUT_DIR
output_dir_module = "#{output_dir}/#{$CODEGEN_MODULE_DIR}"
output_dir_component = "#{output_dir}/#{$CODEGEN_COMPONENT_DIR}"
codegen_config = {
"modules" => {
:js_srcs_pattern => "Native*.js",
:generated_dir => "#{relative_installation_root}/#{output_dir_module}/#{library_name}",
:generated_files => [
"#{library_name}.h",
"#{library_name}-generated.mm"
]
},
"components" => {
:js_srcs_pattern => "*NativeComponent.js",
:generated_dir => "#{relative_installation_root}/#{output_dir_component}/#{library_name}",
:generated_files => [
"ComponentDescriptors.h",
"EventEmitters.cpp",
"EventEmitters.h",
"Props.cpp",
"Props.h",
"RCTComponentViewHelpers.h",
"ShadowNodes.cpp",
"ShadowNodes.h"
]
}
}
# The path to JavaScript files
js_srcs_dir = options[:js_srcs_dir] ||= "./"
library_type = options[:library_type]
if library_type
if !codegen_config[library_type]
raise "[Codegen] invalid library_type: #{library_type}. Check your podspec to make sure it's set to 'modules' or 'components'. Removing the option will generate files for both"
end
js_srcs_pattern = codegen_config[library_type][:js_srcs_pattern]
end
if library_type
generated_dirs = [ codegen_config[library_type][:generated_dir] ]
generated_files = codegen_config[library_type][:generated_files].map { |filename| "#{codegen_config[library_type][:generated_dir]}/#{filename}" }
else
generated_dirs = [ codegen_config["modules"][:generated_dir], codegen_config["components"][:generated_dir] ]
generated_files = codegen_config["modules"][:generated_files].map { |filename| "#{codegen_config["modules"][:generated_dir]}/#{filename}" }
generated_files = generated_files.concat(codegen_config["components"][:generated_files].map { |filename| "#{codegen_config["components"][:generated_dir]}/#{filename}" })
end
if js_srcs_pattern
file_list = `find #{js_srcs_dir} -type f -name #{js_srcs_pattern}`.split("\n").sort
input_files = file_list.map { |filename| "${PODS_TARGET_SRCROOT}/#{filename}" }
else
input_files = [ js_srcs_dir ]
end
# Prepare filesystem by creating empty files that will be picked up as references by CocoaPods.
prepare_command = "mkdir -p #{generated_dirs.join(" ")} && touch -a #{generated_files.join(" ")}"
system(prepare_command) # Always run prepare_command when a podspec uses the codegen, as CocoaPods may skip invoking this command in certain scenarios. Replace with pre_integrate_hook after updating to CocoaPods 1.11
spec.prepare_command = prepare_command
env_files = ["$PODS_ROOT/../.xcode.env.local", "$PODS_ROOT/../.xcode.env"]
Make codegen more reliable on iOS (#30792) Summary: This addesses a few issues I noticed while migrating my app to the new build-time codegen on iOS. 1. I noticed random failures because of codegen on iOS. This is mostly due to the fact the codegen output files are not specified in the xcode script. The only reason it works relatively fine currently is because the codegen output is inside the input files directory. This has the side effect of causing files to be regenerated every build, then causes all core modules to be recompiled which adds up a significant amount of time to rebuilds. To fix this I added the generated files to the script phase output and moved the FBReactNativeSpec dir outside of the codegen source (Libraries). I moved it to the React directory as this seemed to make sense and is where a lot of iOS files are as well as the core modules. Note this might require internal changes. This removes the circular dependency between our build phase input and output so consecutive builds can be cached properly. 2. Add `set -o pipefail` to the xcode script, this helped propagate errors properly to xcode because of the `| tee` pipe so it fails at the script phase and not later with a header not found error. Also add `2>&1` to pipe stderr to stdout so errors are also captured in the log file. 3. Add the `-l` flag to the bash invocation to help finding the yarn binary. With my setup yarn is added to the system PATH in my user .profile. Adding this file will cause bash to source the user environment which xcode scripts does not by default. I think this will help with most setups. 4. If yarn is not found the `command -v yarn` would make the script exit without any output because of the -e flag. I made a change to ignore the return code and check later if YARN_BINARY is set and have an explicit error message if not. ## Changelog [iOS] [Fixed] - Make codegen more reliable on iOS Pull Request resolved: https://github.com/facebook/react-native/pull/30792 Test Plan: Tested various project states to make sure the build always succeeds in RN tester: - Simulate fresh clone, remove all ignored files, install pods, build - Build, delete FBReactNativeSpec generated files, build again - Build, build again, make sure FBReactNativeSpec is cached and not rebuilt - Make the script fail and check that xcode shows the script error logs properly ![image](https://user-images.githubusercontent.com/2677334/105891571-c8badd00-5fde-11eb-839c-259d8e448523.png) Note: Did not test fabric Reviewed By: fkgozali Differential Revision: D26104213 Pulled By: hramos fbshipit-source-id: e18d9a0b9ada7c0c2e608d29ffe88087f04605b4
2021-02-02 01:36:52 +03:00
spec.script_phase = {
:name => 'Generate Specs',
:input_files => input_files + env_files, # This also needs to be relative to Xcode
:output_files => ["${DERIVED_FILE_DIR}/codegen-#{library_name}.log"].concat(generated_files.map { |filename| "${PODS_TARGET_SRCROOT}/#{filename}"} ),
# The final generated files will be created when this script is invoked at Xcode build time.
:script => get_script_phases_no_codegen_discovery(
react_native_path: react_native_path,
codegen_output_dir: $CODEGEN_OUTPUT_DIR,
codegen_module_dir: $CODEGEN_MODULE_DIR,
codegen_component_dir: $CODEGEN_COMPONENT_DIR,
library_name: library_name,
library_type: library_type,
js_srcs_pattern: js_srcs_pattern,
js_srcs_dir: js_srcs_dir,
file_list: file_list
),
Make codegen more reliable on iOS (#30792) Summary: This addesses a few issues I noticed while migrating my app to the new build-time codegen on iOS. 1. I noticed random failures because of codegen on iOS. This is mostly due to the fact the codegen output files are not specified in the xcode script. The only reason it works relatively fine currently is because the codegen output is inside the input files directory. This has the side effect of causing files to be regenerated every build, then causes all core modules to be recompiled which adds up a significant amount of time to rebuilds. To fix this I added the generated files to the script phase output and moved the FBReactNativeSpec dir outside of the codegen source (Libraries). I moved it to the React directory as this seemed to make sense and is where a lot of iOS files are as well as the core modules. Note this might require internal changes. This removes the circular dependency between our build phase input and output so consecutive builds can be cached properly. 2. Add `set -o pipefail` to the xcode script, this helped propagate errors properly to xcode because of the `| tee` pipe so it fails at the script phase and not later with a header not found error. Also add `2>&1` to pipe stderr to stdout so errors are also captured in the log file. 3. Add the `-l` flag to the bash invocation to help finding the yarn binary. With my setup yarn is added to the system PATH in my user .profile. Adding this file will cause bash to source the user environment which xcode scripts does not by default. I think this will help with most setups. 4. If yarn is not found the `command -v yarn` would make the script exit without any output because of the -e flag. I made a change to ignore the return code and check later if YARN_BINARY is set and have an explicit error message if not. ## Changelog [iOS] [Fixed] - Make codegen more reliable on iOS Pull Request resolved: https://github.com/facebook/react-native/pull/30792 Test Plan: Tested various project states to make sure the build always succeeds in RN tester: - Simulate fresh clone, remove all ignored files, install pods, build - Build, delete FBReactNativeSpec generated files, build again - Build, build again, make sure FBReactNativeSpec is cached and not rebuilt - Make the script fail and check that xcode shows the script error logs properly ![image](https://user-images.githubusercontent.com/2677334/105891571-c8badd00-5fde-11eb-839c-259d8e448523.png) Note: Did not test fabric Reviewed By: fkgozali Differential Revision: D26104213 Pulled By: hramos fbshipit-source-id: e18d9a0b9ada7c0c2e608d29ffe88087f04605b4
2021-02-02 01:36:52 +03:00
:execution_position => :before_compile,
:show_env_vars_in_log => true
}
end
# This provides a post_install workaround for build issues related Xcode 12.5 and Apple Silicon (M1) machines.
# Call this in the app's main Podfile's post_install hook.
# See https://github.com/facebook/react-native/issues/31480#issuecomment-902912841 for more context.
# Actual fix was authored by https://github.com/mikehardy.
# New app template will call this for now until the underlying issue is resolved.
def __apply_Xcode_12_5_M1_post_install_workaround(installer)
# Flipper podspecs are still targeting an older iOS deployment target, and may cause an error like:
# "error: thread-local storage is not supported for the current target"
# The most reliable known workaround is to bump iOS deployment target to match react-native (iOS 11 now).
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
Fix post_install_workaround downgrading development targets (#32633) 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 https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523 ## Changelog <!-- 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: https://github.com/facebook/react-native/pull/32633 Test Plan: ### Test (failing before this patch, passing after this patch) 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
2021-11-30 21:20:39 +03:00
# ensure IPHONEOS_DEPLOYMENT_TARGET is at least 11.0
deployment_target = config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'].to_f
should_upgrade = deployment_target < 11.0 && deployment_target != 0.0
Fix post_install_workaround downgrading development targets (#32633) 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 https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523 ## Changelog <!-- 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: https://github.com/facebook/react-native/pull/32633 Test Plan: ### Test (failing before this patch, passing after this patch) 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
2021-11-30 21:20:39 +03:00
if should_upgrade
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '11.0'
end
Fix post_install_workaround downgrading development targets (#32633) 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 https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523 ## Changelog <!-- 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: https://github.com/facebook/react-native/pull/32633 Test Plan: ### Test (failing before this patch, passing after this patch) 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
2021-11-30 21:20:39 +03:00
end
end
# But... doing so caused another issue in Flipper:
# "Time.h:52:17: error: typedef redefinition with different types"
Fix post_install_workaround downgrading development targets (#32633) 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 https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523 ## Changelog <!-- 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: https://github.com/facebook/react-native/pull/32633 Test Plan: ### Test (failing before this patch, passing after this patch) 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
2021-11-30 21:20:39 +03:00
# We need to make a patch to RCT-Folly - remove the `__IPHONE_OS_VERSION_MIN_REQUIRED` check.
# See https://github.com/facebook/flipper/issues/834 for more details.
time_header = "#{Pod::Config.instance.installation_root.to_s}/Pods/RCT-Folly/folly/portability/Time.h"
fix: "Time.h:52:17: error: typedef redefinition with different types" when a folder in the file path has a space (#34510) Summary: The `sed` workaround here in `__apply_Xcode_12_5_M1_post_install_workaround`: https://github.com/facebook/react-native/blob/main/scripts/react_native_pods.rb#L293-L298 does not work when the react native project has a parent folder with a space in the the name, for example: `/Users/myuser/Some Folder/my-project/ios/Pods/RCT-Folly/folly/portability/Time.h` This is because the `sed` command thinks that the part after the space is a separate argument. This bug caused one of our engineers to not be able to run our React Native project through no fault of his own, so I would like to propose this change to help other engineers avoid this in the future. ## Changelog Add single quotes around the file parameter in the `sed` command [iOS] [Fixed] - Fixed Time.h:52:17: error when a folder in the file path has a space Pull Request resolved: https://github.com/facebook/react-native/pull/34510 Test Plan: Checkout the main branch. Create a React Native project in a folder that has a space in the name. When you run `pod install`, you should notice a `sed` error indicating that the text replacement failed. Run the build to reproduce the `Time.h:52:17: error`. Checkout this branch. Run `pod install` and notice the `sed` error is gone. Run the build, the error should be gone. Reviewed By: sammy-SC Differential Revision: D39082262 Pulled By: cipolleschi fbshipit-source-id: 211099234edc6c9ee959bb61a760a6ca04a7a301
2022-08-30 14:10:10 +03:00
`sed -i -e $'s/ && (__IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_10_0)//' '#{time_header}'`
end