Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

0.64 stable new template fails when using use_frameworks! #31149

Closed
Qwin opened this issue Mar 13, 2021 · 16 comments
Closed

0.64 stable new template fails when using use_frameworks! #31149

Qwin opened this issue Mar 13, 2021 · 16 comments

Comments

@Qwin
Copy link

Qwin commented Mar 13, 2021

Getting an error when I take the default template using "npx react-native init" and then changing Podfile to use "use_frameworks!". (removed flipper)

Cycle inside FBReactNativeSpec; building could produce unreliable results. This usually can be resolved by moving the shell script phase '[CP-User] Generate Specs' so that it runs before the build phase that depends on its outputs.
Cycle details:
→ Target 'FBReactNativeSpec' has link command with output '/Users/robertalmalak/Library/Developer/Xcode/DerivedData/testreact-derxgqraechlsxbpbivbctupykqo/Build/Products/Debug-iphonesimulator/FBReactNativeSpec/FBReactNativeSpec.framework/FBReactNativeSpec'
○ Target 'FBReactNativeSpec' has compile command with input '/Users/robertalmalak/testreact/testreact/ios/Pods/Target Support Files/FBReactNativeSpec/FBReactNativeSpec-dummy.m'
○ That command depends on command in Target 'FBReactNativeSpec': script phase “[CP-User] Generate Specs”
○ Target 'FBReactNativeSpec' has copy command from '/Users/robertalmalak/testreact/testreact/node_modules/react-native/React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec.h' to '/Users/robertalmalak/Library/Developer/Xcode/DerivedData/testreact-derxgqraechlsxbpbivbctupykqo/Build/Products/Debug-iphonesimulator/FBReactNativeSpec/FBReactNativeSpec.framework/Headers/FBReactNativeSpec.h'
○ That command depends on command in Target 'FBReactNativeSpec': script phase “[CP-User] Generate Specs”

@Qwin
Copy link
Author

Qwin commented Mar 13, 2021

well I found a workaround, but I am not sure why this works or if it has any side effect but my app has started working:
image

just check the "for install builds only" and boom it will build without cycle error

Looking up the docs on this, it means its only run when you archive your project... hmm that means I am pretty much skipping this step. So somehow the sh react-native/scripts/generate-specs.sh is causing he issue

@Qwin
Copy link
Author

Qwin commented Mar 13, 2021

found another workaround instead of skipping it like above you can also just change the build phase order where the Generate Specs is above the headers step:
image

@Qwin
Copy link
Author

Qwin commented Mar 15, 2021

I also noticed after researching the react code that the ruby pod file (react_native_pods.rb) has an environment var "DISABLE_CODEGEN='1'" which disables this build phase generation all together.

image

so to put it simply:
export DISABLE_CODEGEN="1"
pod install

You will notice that the build phase Generate Specs will be gone. I can't imagine anyone using that build step as of now as I am thinking its only used for the new architecture of react native... this makes me wonder why its not disabled by default.

Sadly I couldnt modify the :execution_position => :before_compile to before_header as that doesn't exists.

@maestor
Copy link

maestor commented Mar 16, 2021

I had issues also with clean installation and without use_frameworks!, iOS didn't built.

Don't know if related, but my issue was related to thing that I started ios build with yarn. It's related somehow to the fact that this Generate Specs is npm script and won't execute correctly if you run with yarn. After I tried just npx react-native run-ios from manual -> build success.

@Fawxy
Copy link

Fawxy commented Mar 16, 2021

Having the same issue here with an existing project and with a fresh template.

@martintreurnicht
Copy link

martintreurnicht commented Mar 17, 2021

found another workaround instead of skipping it like above you can also just change the build phase order where the Generate Specs is above the headers step:
image

I just moved it above headers build phase and used patch-package for now, i see no reason why moving that script can't be the permanent fix

Turns out the package-patch isn't doing anything, after further investigation it seems it's because react_native_pods.rb is where the scripts is being added, and it's using :execution_position => :before_compile which which is why it's in the wrong position, unfortunately it seems like there isn't much options for :execution_position, so unless you can reorganize the scripts order via Podfile, i think we're kinda screwed

@martintreurnicht
Copy link

It's a bit of a hack, but it will fix the issue while waiting for an official fix from RN, add this to your Podfile:

# need to move 'Generate Specs' build_phase to be first for FBReactNativeSpec
post_install do |installer|
    installer.pods_project.targets.each do |target|
      if (target.name&.eql?('FBReactNativeSpec'))
        target.build_phases.each do |build_phase|
          if (build_phase.respond_to?(:name) && build_phase.name.eql?('[CP-User] Generate Specs'))
            target.build_phases.move(build_phase, 0)
          end
        end
      end
    end

@lloydsheng
Copy link

@marcelkalveram Thanks you, the fix works!

mikehardy added a commit to mikehardy/rnfbdemo that referenced this issue Mar 30, 2021
@mikehardy
Copy link
Contributor

indeed - combo of use_frameworks and react-native 0.64.0 needs @martintreurnicht fix above, I cross-linked a commit implementing it in a repo I maintain to demonstrate successful builds for the react-native-firebase repo

You can use that script as a reproducible example if you like - the sed line included (which slices in Martin's fix) can be toggled on or off to reproduce the failure, but the repo starts from scratch with a clean react-native template so hopefully it's useful.

@mikehardy
Copy link
Contributor

Just a note for everyone that this is still an unresolved issue for iOS users with static_frameworks as far as I know?
It was linked to the 0.64.2 cherrypicks discussion but is listed as unresolved.

Unsure on status for 0.65 but I imagine it is not resolved there as I see no related PR linked or commit reference

I'm still using the Podfile hack above successfully when instructing others how to build

@billnbell
Copy link
Contributor

what is the status of this one?

@mikehardy
Copy link
Contributor

This is related to react-native 0.64 which is so long ago that in the meantime building for macCatalyst broke complete, then was fixed, and then was fixed for use_frameworks ;-). I don't anticipate any motion on this one. I'm focused on react-native 0.70 cherry-picks, happy to see the CI matrix expanded to check use_frameworks to prevent regression in future (https://github.com/facebook/react-native/pulls?q=is%3Apr+matrix+sort%3Aupdated-desc ) and examining the 0.71 release when it comes out.

@mikehardy
Copy link
Contributor

Irony (?), I just realized this is still live in my make-demo.sh script and just copy-pasted it in to my Podfile, but I'm not sure if it's strictly required or not. It was actually building correctly without it (react-native 0.69.5 + react-native-firebase@current), but I fear taking it out at the moment as I'm struggling with enough things that this one - which at worst should do no harm - seems okay to keep for a bit until I can test taking it out more thoroughly

Maybe others on this issue have more concrete info / experience

@ZXY101
Copy link

ZXY101 commented Oct 18, 2022

Just chipping in, I used your make-demo.sh script as reference to get a new project working with RNFB and managed to get it building without the above fix, react-native: 0.70.2 + @react-native-firebase/app: ^15.7.0

@mikehardy
Copy link
Contributor

Thanks, happy to hear a success report on current stable, I'll remove this baggage from my script and see how it goes

@cortinico
Copy link
Contributor

Closing as all the use_frameworks! issues have been resolved in the latest stable of RN

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants