Summary:
We accidentally added `-DCMAKE_BUILD_TYPE=Debug` for Hermes which is causing
a really slow engine execution. This fixes it and keep the -DCMAKE_BUILD_TYPE
aligned with the one used on Android.
Changelog:
[iOS] [Fixed] - Correctly set -DCMAKE_BUILD_TYPE for Hermes on iOS
Reviewed By: hramos, cipolleschi
Differential Revision: D40980934
fbshipit-source-id: 30f0455990a911b51eb109bebca8272507302650
Summary:
This PR is a follow up of https://github.com/facebook/react-native/pull/35075 and https://github.com/facebook/react-native/commit/1546666a6d713ef756b2f11de9581e3b2bbe08dc to ensure that even in the local e2e testing scenario the new maven approach is followed - without this, RNTestProject on Android won't work, like so:
<img width="1905" alt="Screenshot 2022-10-27 at 12 15 38" src="https://user-images.githubusercontent.com/16104054/198334105-30fb2037-4e7c-4814-8c3f-2412ba0bd49f.png">
And iOS will always build everything from source every time.
This PR addresses both by generating the artifacts locally, and passing them to RNTestProject as if they were coming from a url (mimicking as closely as possible the behaviour for the final user)
In doing so, there's been some refactoring to prep the ground for follow up work.
* refactor CI to rely less on scripts directly in the CircleCI config, but invoke .js ones
* we should be able to trigger more the "manual" artifacts generation so that it will only happen once between RNTester and RNTestProject, and we can pass existing artifacts to the other flows.
* once all of this in place, a very good improvement would be to be able to download the maven artifacts kind of like nightlies and stables do. This will only be viable by checking that there's no local changes, after which there needs to be logic to pull down from CircleCI the artifacts based on git commit <-> circleCI job references.
---
While at it, I've also fixed the hermes-engine podspec logic for detecting if it's on CI: basically the local e2e script needs to align with the changes done here: https://github.com/facebook/react-native/commit/4b512077354eb4702ce144e9958d7513c1607275
but as you can see there, the condition was actually inconsistent across the various files, so realigned to `CI === 'true'`. We probably didn't catch that so far 'cause the other condition in the hermes podspect (existence of `hermestag_file`) is only true on release branches and this new logic has not been in any release branches yet.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - add logic to local e2e script to handle maven local for iOS and Android accordingly
Pull Request resolved: https://github.com/facebook/react-native/pull/35104
Test Plan:
Run ` yarn test-e2e-local -t RNTestProject -p Android` successfully.
Run ` yarn test-e2e-local -t RNTestProject -p iOS` successfully. On the pod install stage, you will see `[Hermes] Using pre-built Hermes binaries from local path.`
Reviewed By: dmytrorykun
Differential Revision: D40893239
Pulled By: cipolleschi
fbshipit-source-id: a31217ec4f177383c62292d00fabc4cbe4391cfd
Summary:
Include dSYMs when building the universal XCFramework for Hermes iOS.
CocoaPods should pick up dSYMs automatically when using `vendored_framework` if:
- `hermes.framework` has a `hermes.framework.dSYM` in the same base directory
- `hermes.xcframework` has a `dSYMs` folder with a `hermes.framework.dSYM` in it, for each slice
The dSYMs for the macOS hermes.framework are already being created.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40790250
fbshipit-source-id: 50fcb3492434637b00458c1aa443ac6ec5472fac
Summary:
## Context
If React Native is built from *main* of any non-stable commit, then Hermes is built from source. The build is performed by `build-ios-framework.sh` and `build-mac-framework.sh` scripts in `hermes-engine.podspec` `prepare_command` stage. Since those scripts have no access build target information, they build all possible architectures and platforms just in case. That takes ages.
## Solution
The idea is to integrate build script into Xcode *run script* phase, and use build target information to build Hermes for active architecture only.
## Implementation
- Existing behaviour remains unchanged for local tarball and remote prebuild cases.
- `build-hermesc-xcode.sh` builds Hermesc as `hermes-engine.podspec` `prepare_command`. Default build location is `react-native/sdks/hermes-engine/build_host_hermesc`.
- `build-hermes-xcode.sh` builds Hermes in 'Build Hermes' Xcode script phase. It uses `$PLATFORM_NAME`, `$CONFIGURATION`, `$ARCHS`, `$IPHONEOS_DEPLOYMENT_TARGET` and `$MACOSX_DEPLOYMENT_TARGET` environment variables to configure cmake project so it builds only active architecture. The script also gets RN version, *cmake* path and *hermesc* path from the podspec.
- `copy-hermes-xcode.sh` copies Hermes.framework inside the app bundle. This script phase is added to the user app target in a `post_install` hook, after pods are integrated in a user project.
- `OTHER_LDFLAGS -framework "hermes"` added to the user project to enable linking against Hermes.framework.
- If `HERMES_OVERRIDE_HERMESC_PATH` is set, then Hermesc building is skipped, and `HERMES_OVERRIDE_HERMESC_PATH` is used for `build-hermes-xcode.sh`.
- `HERMES_CLI_PATH` is injected into user project config to enable Hermes source maps in `react-native-xcode.sh`.
## Things that didn't work
- *Running build-hermesc-xcode.sh in Xcode run script phase*. This doesn't work because Hermesc is supposed to be built for macos, and if build target is ios, then Xcode configures environment in such a way that Hermesc build fails.
- *Installing Hermesc into CocoaPods download folder*. So it then ends up in `Pods/hermes-engine/build_host_hermesc`, and all the housekeeping is handled by CocoaPods. This doesn't work because cmake uses absolute paths in a configured project. If configured project is moved to a different location, nothing builds.
- *Installing Hermesc directly into Pods/hermes-engine*. This doesn't work because CocoaPods runs prepare_command before Pods folder clean up, and everything gets wiped.
## Known issue
- If `Pods/hermes-engine` is manually removed, then `sdks/hermes-engine/build_host_hermesc` must also be removed before running `pod install`. Otherwise cmake will complain about stale cache:
```
CMake Error: The source "<CocoaPodsCache>/hermes-engine/<hash2>/CMakeLists.txt" does not match the source
"<CocoaPodsCache>/hermes-engine/<has1>/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
```
## Benchmark
MacBook M1 2021 32 GB.
```
export REACT_NATIVE_PATH=~/fbsource/xplat/js/react-native-github
cd $REACT_NATIVE_PATH/packages/rn-tester
pod install
rm -rf $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
echo 't1=$(date +%s); $@; t2=$(date +%s); diff=$(echo "$t2 - $t1" | bc); echo Operation took $diff seconds.' > /tmp/benchmark.sh
```
```
# Before
export BUILD_TYPE=Debug
export JSI_PATH=$REACT_NATIVE_PATH/ReactCommon/jsi
export RELEASE_VERSION=1000.0
export IOS_DEPLOYMENT_TARGET=iphonesimulator
export MAC_DEPLOYMENT_TARGET=12.6
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-ios-framework.sh
# Operation took 252 seconds
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-mac-framework.sh
# Operation took 179 seconds
```
```
# After
. /tmp/benchmark.sh source $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-hermesc-xcode.sh $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
# Operation took 59 seconds.
. /tmp/benchmark.sh xcodebuild -workspace $REACT_NATIVE_PATH/packages/rn-tester/RNTesterPods.xcworkspace -scheme hermes-engine
# Operation took 106 seconds.
```
|Before|||After|||
|--|
|iOS framework (s)|Mac framework (s)|Total (s)|Hermesc (s)|Target-specific framework (s)|Total (s)|
|252|179|431|59|106|**165 (-266) (-61%)**|
The performance win is fixed, and does not depend on the project size and structure.
As an example, this is how these changes affect build time of RNTester.
|Before||||After|||
|--|
||Pod install (s)|Xcode build (s)|Total (s)|Pod install (s)|Xcode build (s)|Total (s)|
|Clean build|1219|132|1352|734 (-485)|249(+117)|**983 (-369)**|
|Incremental build|82|30|112|105 (+23)|**34 (+4)**|139 (+27)|
The most important values here are the total clean build time and the incremental Xcode build time. The first one went down by 369 seconds, the second one went up by 4 seconds. I consider it a reasonable tradeoff.
The extra 4 seconds in the incremental Xcode build time can potentially be mitigated by setting up output file lists for the new script phases.
allow-large-files
Changelog:
[iOS][Changed] - Hermes is integrated into Xcode build.
Reviewed By: hramos
Differential Revision: D40063686
fbshipit-source-id: e6993d62225789377db769244bc07786cc978a27
Summary:
Within the `hermes-engine.podspec` contained in the RN repo (at `react-native/main/sdks/hermes-engine/`), there's a bit of logic that triggers `./utils/build-ios-framework.sh` and `./utils/build-mac-framework.sh` .
The issue is that we all thought that that `./utils/build-ios-framework.sh` would invoke the React native version of the scripts (since the podspec file lives right next to the `utils` folder) but, in reality, it doesn't. It just so happens that the Hermes repo has a root level `utils` folder which is (you guessed it) where the Hermes variation of those build scripts live.
So, when running the pod install command in a react-native project (build from source), it will go and download the hermes source code (since the `source[:git]` gets set) but then it will use the **hermes** variation of the `build-*.sh` scripts.
[Read more here](https://github.com/facebook/react-native/pull/34513#issuecomment-1248286691).
This PR is taking kudo's proposed [patch here](https://github.com/reactwg/react-native-new-architecture/discussions/68#discussioncomment-3654191) - props for the fix go to him.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Change hermes logic in build scripts for Apple to use the correct files
Pull Request resolved: https://github.com/facebook/react-native/pull/34710
Test Plan: Tested by kudo in his work, and in my PR locally - [see here](https://github.com/facebook/react-native/pull/34513#issuecomment-1249431302).
Reviewed By: cortinico
Differential Revision: D39647057
Pulled By: cipolleschi
fbshipit-source-id: 6520e248801a307ca2f8886a3853dd1ff4af193d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34704
Create separate hermes-engine tarballs for release and debug builds, and only include the debugger in debug builds.
Changes the hermes-engine podspec to use a debug Hermes build by default in order to preserve the inclusion of the debugger.
Upcoming changes should split the hermes-engine Pod to allow Xcode to use release and debug builds as needed.
Changelog:
[iOS][Changed] - Use debug Hermes builds by default
Reviewed By: cipolleschi
Differential Revision: D39326467
fbshipit-source-id: 94c5fe7db80194d22fced6717c5efc7accd36d48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33885
When building Hermes for React Native, point to the React Native JSI location to ensure both React Native and Hermes use the exact same version of JSI.
Changelog:
[iOS] [Changed] - When Hermes is enabled, it will use the same copy of JSI as React Native
Reviewed By: cortinico, cipolleschi
Differential Revision: D36567471
fbshipit-source-id: 97d954ef34007bd31f008fab451512194060d670
Summary:
Use pre-built hermesc if available by generating a ImportHermesc.cmake file that points to the hermesc binary. Recent `react-native` releases should have hermesc available in sdks/hermesc.
Hermes build scripts have been updated to support a `HERMES_OVERRIDE_HERMESC_PATH` envvar which can point to this generated ImportHermesc.cmake file.
Pull Request resolved: https://github.com/facebook/react-native/pull/33827
Changelog:
[iOS] [Changed] - Use pre-built HermesC if available in current React Native release
Reviewed By: cortinico
Differential Revision: D36024615
fbshipit-source-id: 476569f73309f9bd142f28cb02d1f7d57b6cbc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33811
Use `scripts/hermes/prepare-hermes-for-build.js` in Circle CI, eliminating redundant steps in the `prepare_hermes_workspace` Circle CI job.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D36335122
fbshipit-source-id: b7e8c7aeb2aac5afaf37677cd3ac949ac3f96de1
Summary:
Hermes' build scripts use the Ninja build utility if available, otherwise they default to Unix Makefiles. When Unix Makefiles were used, builds would take far too long due to the use of a single core.
To reduce the surface area of issues that may arise as we switch to building Hermes from source, we will now focus on a single build system using Unix Makefiles. We will also ensure all available cores are used when building on macOS.
Changelog: [Internal]
Reviewed By: cortinico, neildhar
Differential Revision: D36296838
fbshipit-source-id: 4be23739fb022e3ae8e974ad3c2c70e7011abb5a
Summary:
Copy Hermes build scripts to React Native repository for greater control over the build pipeline when used in RN.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D36295406
fbshipit-source-id: 54bf4173b6c75db35de828378e6f5782a248ed2e
Nicola Corti
Lorenzo Sciandra
Héctor Ramos
Dmitry Rykun
Lorenzo Sciandra
Neil Dhar
Héctor Ramos
