Fix ios build error when podfile generate_multiple_pod_projects=true and fabric is on by Kudo · Pull Request #33381 · react/react-native

Kudo · 2022-03-04T11:40:14Z

Summary

there are build errors happened when in generate_multiple_pod_projects 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 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

Test Plan

verify with rn-tester

add generate_multiple_pod_projects

--- 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'

pod install and build rn-tester from xcode

analysis-bot · 2022-03-04T11:58:22Z

Platform	Engine	Arch	Size (bytes)	Diff
ios	-	universal	n/a	--

Base commit: b676ca5
Branch: main

analysis-bot · 2022-03-04T12:20:50Z

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,214,216	+0
android	hermes	armeabi-v7a	7,799,918	+0
android	hermes	x86	8,587,706	+0
android	hermes	x86_64	8,538,641	+0
android	jsc	arm64-v8a	9,882,916	+0
android	jsc	armeabi-v7a	8,853,162	+0
android	jsc	x86	9,852,501	+0
android	jsc	x86_64	10,447,566	+0

Base commit: b676ca5
Branch: main

ShikaSD · 2022-03-11T13:38:28Z

I am not sure importing private header folders is a correct idea here, maybe we should expose all relevant ones from the Yoga.podspec?

i've updated this pr to expose all yoga headers. the solution is a little tricky as the podspec comment and pr description said. please help to review when you get a chance and feel free to give me any comments.

cortinico · 2022-03-11T17:15:22Z

@Kudo is this still needed?

Kudo · 2022-03-11T17:21:46Z

@Kudo is this still needed?

yes, @ShikaSD's comment makes sense to me. it's not easy as expect because we should not expose c++ headers to clang module, otherwise it breaks swift integration (YogaKit). i'm still trying different approach. will update here once i'm find some solutions.

…te_multiple_pod_projects=true

facebook-github-bot · 2022-03-12T15:38:32Z

@ShikaSD has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

react-native-bot · 2022-04-11T13:10:04Z

This pull request was successfully merged by @Kudo in 65abc36.

^{When will my fix make it into a release? | Upcoming Releases}

Summary: X-link: react/react-native#36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module react/react-native#33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. But also I have no idea what I'm doing here, so this will be exported and built. Changelog: [Internal] Differential Revision: D45139075 fbshipit-source-id: ed4c73f465bb73d23a2b22d1fed340d3cd41fe45

Summary: Pull Request resolved: react#1252 X-link: react/react-native#36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module react/react-native#33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. Changelog: [Internal] Differential Revision: D45139075 fbshipit-source-id: af4c7c82ca15276a72c024d98cf44134da27497d

Summary: X-link: react/yoga#1252 X-link: react/react-native#36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module react/react-native#33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. Changelog: [Internal] Differential Revision: D45139075 fbshipit-source-id: 8f1878f602b732cdd928a1311a6bedf85afe12ca

Summary: X-link: facebook/litho#940 X-link: react/yoga#1252 Pull Request resolved: react#36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module react#33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. Changelog: [Internal] Reviewed By: rshest Differential Revision: D45139075 fbshipit-source-id: 96dab7b73f5164cb5103674d074d0759dad9c8b0

Summary: X-link: facebook/litho#940 Pull Request resolved: #1252 X-link: react/react-native#36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module react/react-native#33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. Changelog: [Internal] Reviewed By: rshest Differential Revision: D45139075 fbshipit-source-id: 99152986a578f7aac8324dffe0e18c42a38cc6a5

Summary: Pull Request resolved: #940 X-link: react/yoga#1252 X-link: react/react-native#36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module react/react-native#33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. Changelog: [Internal] Reviewed By: rshest Differential Revision: D45139075 fbshipit-source-id: 99152986a578f7aac8324dffe0e18c42a38cc6a5

Summary: X-link: facebook/litho#940 X-link: react/yoga#1252 Pull Request resolved: #36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module #33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. Changelog: [Internal] Reviewed By: rshest Differential Revision: D45139075 fbshipit-source-id: 99152986a578f7aac8324dffe0e18c42a38cc6a5

Summary: This change is mostly needed to support the new react-native architecture with Swift. Some private yoga headers end up being included in the swift build and result in compilation failure since swift cannot compile c++ modules. See react/react-native#33381. The most reliable fix is to include all headers as public headers, and add `#ifdef __cplusplus` to those that include c++. This is already what we do for other headers, this applies this to all headers. Tested in the YogaKitSample, and also in a react-native app. Changelog: [iOS] [Changed] - Make all Yoga headers public and add #ifdef __cplusplus Pull Request resolved: react/yoga#1150 Reviewed By: dmitryrykun Differential Revision: D36966687 Pulled By: cortinico fbshipit-source-id: a34a54d56df43ab4934715070bab8e790b9abd39

Summary: X-link: facebook/litho#940 Pull Request resolved: react/yoga#1252 X-link: react/react-native#36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module react/react-native#33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. Changelog: [Internal] Reviewed By: rshest Differential Revision: D45139075 fbshipit-source-id: 99152986a578f7aac8324dffe0e18c42a38cc6a5

Summary: This change is mostly needed to support the new react-native architecture with Swift. Some private yoga headers end up being included in the swift build and result in compilation failure since swift cannot compile c++ modules. See react/react-native#33381. The most reliable fix is to include all headers as public headers, and add `#ifdef __cplusplus` to those that include c++. This is already what we do for other headers, this applies this to all headers. Tested in the YogaKitSample, and also in a react-native app. Changelog: [iOS] [Changed] - Make all Yoga headers public and add #ifdef __cplusplus Pull Request resolved: react/yoga#1150 Reviewed By: dmitryrykun Differential Revision: D36966687 Pulled By: cortinico fbshipit-source-id: a34a54d56df43ab4934715070bab8e790b9abd39

Summary: X-link: facebook/litho#940 Pull Request resolved: react/yoga#1252 X-link: react/react-native#36993 Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works. 1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default) 2. Cocoapods will roll up all of the public headers when importing a module react/react-native#33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI. The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment. Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header. Changelog: [Internal] Reviewed By: rshest Differential Revision: D45139075 fbshipit-source-id: 99152986a578f7aac8324dffe0e18c42a38cc6a5

facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Contributor A React Native contributor. p: Expo Partner: Expo Partner labels Mar 4, 2022

Kudo force-pushed the fix-multi-pod-project-errors branch from eb34db0 to 7755031Compare March 4, 2022 11:42

react-native-bot added Bug Platform: iOS iOS applications. labels Mar 4, 2022

Kudo marked this pull request as ready for review March 4, 2022 12:29

kelset added the Needs: React Native Team Attention label Mar 4, 2022

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Mar 4, 2022

mikehardy reviewed Mar 4, 2022
View reviewed changes

Comment threadReact/React-RCTFabric.podspec Outdated

Kudo force-pushed the fix-multi-pod-project-errors branch from 7755031 to 614b3baCompare March 7, 2022 12:27

ShikaSD reviewed Mar 11, 2022
View reviewed changes

Kudo force-pushed the fix-multi-pod-project-errors branch from 614b3ba to 9ba4b2dCompare March 11, 2022 20:04

Kudo added 2 commits March 12, 2022 04:06

Pass -DRCT_NEW_ARCH_ENABLED=1 to every projects when podfile genera…
55adbf2
…te_multiple_pod_projects=true

expose all yoga headers but not for modular headers
af1a619

Kudo force-pushed the fix-multi-pod-project-errors branch from 9ba4b2d to af1a619Compare March 11, 2022 20:06

ShikaSD requested a review from dmytrorykun March 12, 2022 15:38

facebook-github-bot closed this in 65abc36Apr 11, 2022

react-native-bot added the Merged This PR has been merged. label Apr 11, 2022

NickGerleman mentioned this pull request Apr 20, 2023
Testing: Remove private headers from podspecs (#36993) react/yoga#1252
Closed

NickGerleman mentioned this pull request Apr 24, 2023
Remove private headers exposed by podspecs (#1252) facebook/litho#940
Closed

Navigation Menu

Uh oh!

Fix ios build error when podfile generate_multiple_pod_projects=true and fabric is on - #33381

Fix ios build error when podfile generate_multiple_pod_projects=true and fabric is on#33381
Kudo wants to merge 2 commits into
react:mainfrom
Kudo:fix-multi-pod-project-errors

Kudo commented Mar 4, 2022•
edited
Loading

Uh oh!

analysis-bot commented Mar 4, 2022•
edited
Loading

Uh oh!

analysis-bot commented Mar 4, 2022•
edited
Loading

Uh oh!

Uh oh!

ShikaSDMar 11, 2022

Uh oh!

KudoMar 11, 2022

Uh oh!

cortinico commented Mar 11, 2022

Uh oh!

Kudo commented Mar 11, 2022

Uh oh!

facebook-github-bot commented Mar 12, 2022

Uh oh!

react-native-bot commented Apr 11, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Uh oh!

Conversation

Kudo commented Mar 4, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

-DRCT_NEW_ARCH_ENABLED=1 does not pass to RCTAppSetupUtils.mm

fatal error: 'CompactValue.h' file not found

Changelog

Test Plan

Uh oh!

analysis-bot commented Mar 4, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

analysis-bot commented Mar 4, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

ShikaSDMar 11, 2022

Choose a reason for hiding this comment

Uh oh!

KudoMar 11, 2022

Choose a reason for hiding this comment

Uh oh!

cortinico commented Mar 11, 2022

Uh oh!

Kudo commented Mar 11, 2022

Uh oh!

facebook-github-bot commented Mar 12, 2022

Uh oh!

react-native-bot commented Apr 11, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Kudo commented Mar 4, 2022•
edited
Loading

`-DRCT_NEW_ARCH_ENABLED=1` does not pass to `RCTAppSetupUtils.mm`

analysis-bot commented Mar 4, 2022•
edited
Loading

analysis-bot commented Mar 4, 2022•
edited
Loading