react-native-macos/Libraries/NativeAnimation/React-RCTAnimation.podspec

48 строки
2.1 KiB
Plaintext
Исходник Обычный вид История

# Copyright (c) Meta Platforms, Inc. and affiliates.
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
#
# This source code is licensed under the MIT license found in the
# LICENSE file in the root directory of this source tree.
require "json"
package = JSON.parse(File.read(File.join(__dir__, "..", "..", "package.json")))
version = package['version']
source = { :git => 'https://github.com/facebook/react-native.git' }
if version == '1000.0.0'
# This is an unpublished version, use the latest commit hash of the react-native repo, which were presumably in.
source[:commit] = `git rev-parse HEAD`.strip if system("git rev-parse --git-dir > /dev/null 2>&1")
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
else
source[:tag] = "v#{version}"
end
folly_compiler_flags = '-DFOLLY_NO_CONFIG -DFOLLY_MOBILE=1 -DFOLLY_USE_LIBCPP=1 -Wno-comma -Wno-shorten-64-to-32'
folly_version = '2021.06.28.00-v2'
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
Pod::Spec.new do |s|
s.name = "React-RCTAnimation"
s.version = version
s.summary = "A native driver for the Animated API."
s.homepage = "https://reactnative.dev/"
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
s.license = package["license"]
s.author = "Facebook, Inc. and its affiliates"
s.platforms = { :ios => "12.4" }
s.compiler_flags = folly_compiler_flags + ' -Wno-nullability-completeness'
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
s.source = source
s.source_files = "**/*.{h,m,mm}"
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
s.preserve_paths = "package.json", "LICENSE", "LICENSE-docs"
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
s.header_dir = "RCTAnimation"
s.pod_target_xcconfig = {
"USE_HEADERMAP" => "YES",
"CLANG_CXX_LANGUAGE_STANDARD" => "c++17",
Fix ios build error when use_frameworks is on and fabric is off (v2) (#33409) Summary: alternative solution for https://github.com/facebook/react-native/issues/33379 > when `use_frameworks!` is on, there are errors like: > ``` > 'FBReactNativeSpec/FBReactNativeSpec.h' file not found > #import <FBReactNativeSpec/FBReactNativeSpec.h> > ``` > this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression. > > when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`. > > > this fix is specific for old architecture (fabric is off). > > when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks. in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable. [this change](https://github.com/facebook/react-native/commit/7a0398c331f22abc619a64b444ec7153357b0a30) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from https://github.com/facebook/react-native/commit/180495159517dc0bfa103621e5ff62fc04cb3c8b. ## Changelog [iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off Pull Request resolved: https://github.com/facebook/react-native/pull/33409 Test Plan: verify with rn-tester 1. change `fabric_enabled` to false in `packages/rn-tester/Podfile` 2. `USE_FRAMEWORKS=1 pod install` 3. build rn-tester in xcode Reviewed By: dmitryrykun Differential Revision: D34817041 Pulled By: cortinico fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
2022-03-11 20:08:07 +03:00
"HEADER_SEARCH_PATHS" => "\"$(PODS_ROOT)/RCT-Folly\" \"${PODS_ROOT}/Headers/Public/React-Codegen/react/renderer/components\" \"${PODS_CONFIGURATION_BUILD_DIR}/React-Codegen/React_Codegen.framework/Headers\""
}
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
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
s.dependency "RCT-Folly", folly_version
s.dependency "React-Codegen", version
s.dependency "RCTTypeSafety", version
s.dependency "ReactCommon/turbomodule/core", version
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
s.dependency "React-jsi", version
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
s.dependency "React-Core/RCTAnimationHeaders", version
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
end