react-native-macos/scripts/react-native-xcode.sh

188 строки
5.3 KiB
Bash
Исходник Обычный вид История

#!/bin/bash
# Copyright (c) Facebook, Inc. and its affiliates.
#
# This source code is licensed under the MIT license found in the
# LICENSE file in the root directory of this source tree.
# Bundle React Native app's code and image assets.
# This script is supposed to be invoked as part of Xcode build process
# and relies on environment variables (including PWD) set by Xcode
# Print commands before executing them (useful for troubleshooting)
set -x
DEST=$CONFIGURATION_BUILD_DIR/$UNLOCALIZED_RESOURCES_FOLDER_PATH
# Enables iOS devices to get the IP address of the machine running Metro
if [[ "$CONFIGURATION" = *Debug* && ! "$PLATFORM_NAME" == *simulator ]]; then
for num in 0 1 2 3 4 5 6 7 8; do
IP=$(ipconfig getifaddr en${num})
if [ ! -z "$IP" ]; then
break
fi
done
iOS build - en0 and en1 used when generating ip.txt file (#25462) Summary: When `en0` is not assigned and `en1` is in use along with another interface present on the machine that uses a self-assigned address (169.254.xxx.xxx), the ip.txt file contains the self-assigned address. This causes the app reload/debug actions to fail when deployed to a physical device. see https://github.com/facebook/react-native/issues/25460 Code change looks at the value assigned to `en1` if `en0` is not set. If `en1` is not available on the machine or not set, then it will be empty. If both `en0` and `en1` are not set, the existing code was modified exclude addresses that are self-assigned, as they will most likely be unavailable to the connected device (iPhone, iPad, etc.). ## Changelog [Internal] [Fixed] - en0 and en1 are used when generating the ip.txt file for iOS device debug builds Pull Request resolved: https://github.com/facebook/react-native/pull/25462 Test Plan: execute `ifconfig`: ``` lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=201<PERFORMNUD,DAD> gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 XHC20: flags=0<> mtu 0 XHC0: flags=0<> mtu 0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV> ether 38:f9:d3:0d:aa:fe nd6 options=201<PERFORMNUD,DAD> media: autoselect (none) status: inactive en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=60<TSO4,TSO6> ether 42:00:84:a8:f6:00 media: autoselect <full-duplex> status: inactive en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=60<TSO4,TSO6> ether 42:00:84:a8:f6:01 media: autoselect <full-duplex> status: active bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=63<RXCSUM,TXCSUM,TSO4,TSO6> ether 42:00:84:a8:f6:00 inet6 fe80::e:80be:b322:79b7%bridge0 prefixlen 64 secured scopeid 0x9 inet 169.254.209.63 netmask 0xffff0000 broadcast 169.254.255.255 Configuration: id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0 maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200 root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0 ipfilter disabled flags 0x2 member: en2 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 7 priority 0 path cost 0 member: en3 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 8 priority 0 path cost 0 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active ap1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 ether 3a:f9:d3:9a:14:05 media: autoselect status: inactive en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 38:f9:d3:9a:14:05 inet6 fe80::1444:113e:d65:5fb3%en1 prefixlen 64 secured scopeid 0xb inet 192.168.1.115 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304 ether 0a:f9:d3:9a:14:05 media: autoselect status: inactive awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484 ether 6a:fe:9d:f0:39:3f inet6 fe80::68fe:9dff:fef0:393f%awdl0 prefixlen 64 scopeid 0xd nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000 inet6 fe80::c992:4ed:9399:85bc%utun0 prefixlen 64 scopeid 0xe nd6 options=201<PERFORMNUD,DAD> utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380 inet6 fe80::f5de:860a:fd07:ee87%utun1 prefixlen 64 scopeid 0xf nd6 options=201<PERFORMNUD,DAD> utun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380 inet6 fe80::3115:b6a0:6625:23ee%utun2 prefixlen 64 scopeid 0x11 nd6 options=201<PERFORMNUD,DAD> en5: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether e2:33:8e:95:93:9b inet6 fe80::cea:8f7a:b379:ebcd%en5 prefixlen 64 secured scopeid 0x10 inet 169.254.167.11 netmask 0xffff0000 broadcast 169.254.255.255 nd6 options=201<PERFORMNUD,DAD> media: autoselect (100baseTX <full-duplex>) status: active ``` execute `ipconfig getifaddr en0`: (produces nothing) execute `ipconfig getifaddr en1`: ``` 192.168.1.115 ``` execute `ipconfig getifaddr en99`: (produces nothing - non-existent case) existing code `ifconfig | grep 'inet ' | grep -v ' 127.' | cut -d\ -f2 | awk 'NR==1{print $1}'` yields: ``` 169.254.209.63 ``` modified code ` ifconfig | grep 'inet ' | grep -v ' 127.' | grep -v ' 169.254.' | cut -d\ -f2 | awk 'NR==1{print $1}'` yields: ``` 192.168.1.115 ``` Differential Revision: D16099639 Pulled By: cpojer fbshipit-source-id: bd480a5f638efc58611d22cef4ba5193052b713d
2019-07-03 12:27:49 +03:00
if [ -z "$IP" ]; then
IP=$(ifconfig | grep 'inet ' | grep -v ' 127.' | grep -v ' 169.254.' |cut -d\ -f2 | awk 'NR==1{print $1}')
fi
echo "$IP" > "$DEST/ip.txt"
fi
if [[ "$SKIP_BUNDLING" ]]; then
echo "SKIP_BUNDLING enabled; skipping."
exit 0;
fi
case "$CONFIGURATION" in
*Debug*)
if [[ "$PLATFORM_NAME" == *simulator ]]; then
if [[ "$FORCE_BUNDLING" ]]; then
echo "FORCE_BUNDLING enabled; continuing to bundle."
else
echo "Skipping bundling in Debug for the Simulator (since the packager bundles for you). Use the FORCE_BUNDLING flag to change this behavior."
exit 0;
fi
else
echo "Bundling for physical device. Use the SKIP_BUNDLING flag to change this behavior."
fi
DEV=true
;;
"")
echo "$0 must be invoked by Xcode"
exit 1
;;
*)
DEV=false
;;
esac
# Path to react-native folder inside node_modules
REACT_NATIVE_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
# The project should be located next to where react-native is installed
# in node_modules.
PROJECT_ROOT=${PROJECT_ROOT:-"$REACT_NATIVE_DIR/../.."}
cd "$PROJECT_ROOT" || exit
# Define entry file
if [[ "$ENTRY_FILE" ]]; then
# Use ENTRY_FILE defined by user
:
elif [[ -s "index.ios.js" ]]; then
ENTRY_FILE=${1:-index.ios.js}
else
ENTRY_FILE=${1:-index.js}
fi
if [[ $DEV != true && ! -f "$ENTRY_FILE" ]]; then
echo "error: Entry file $ENTRY_FILE does not exist. If you use another file as your entry point, pass ENTRY_FILE=myindex.js" >&2
exit 2
fi
# Find path to Node
# shellcheck source=/dev/null
source "$RN_DIR/scripts/find-node.sh"
# check and assign NODE_BINARY env
# shellcheck source=/dev/null
source "$REACT_NATIVE_DIR/scripts/node-binary.sh"
feat: Enable Hermes to work on iOS (#29914) Summary: This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet. Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0) Fixes https://github.com/facebook/react-native/issues/28810 (as above) Checklist: - [x] Adjust release scripts to create Hermes bytecode bundle - [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project) - [x] Test on a new React Native application in both Debug and Release (Device) - [x] Test on an RNTester application in both Debug and Release (Device) - [x] Add missing `i386` to Hermes framework and enable Bitcode - [x] Inspect CI failures for possible regressions - [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810 - [x] Release new Hermes and test against it that everything works ## Changelog [IOS] [FEATURE] - Enable Hermes on iOS [INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues [INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI [INTERNAL] - Fix building RNTester in Release mode [INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!` [INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI [INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway Pull Request resolved: https://github.com/facebook/react-native/pull/29914 Test Plan: Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now. Preview: (note "Engine: Hermes") <img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png"> Reviewed By: hramos Differential Revision: D24684845 Pulled By: cpojer fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
2020-11-03 12:13:01 +03:00
[ -z "$HERMES_CLI_PATH" ] && HERMES_CLI_PATH="$PODS_ROOT/hermes-engine/destroot/bin/hermesc"
if [[ -z "$USE_HERMES" && -f "$HERMES_CLI_PATH" ]]; then
echo "Enabling Hermes byte-code compilation. Disable with USE_HERMES=false if needed."
USE_HERMES=true
fi
if [[ $USE_HERMES == true && ! -f "$HERMES_CLI_PATH" ]]; then
echo "error: USE_HERMES is set to true but the hermesc binary could not be " \
"found at ${HERMES_CLI_PATH}. Perhaps you need to run pod install or otherwise " \
"point the HERMES_CLI_PATH variable to your custom location." >&2
exit 2
fi
[ -z "$NODE_ARGS" ] && export NODE_ARGS=""
[ -z "$CLI_PATH" ] && export CLI_PATH="$REACT_NATIVE_DIR/cli.js"
[ -z "$BUNDLE_COMMAND" ] && BUNDLE_COMMAND="bundle"
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
[ -z "$COMPOSE_SOURCEMAP_PATH" ] && COMPOSE_SOURCEMAP_PATH="$REACT_NATIVE_DIR/scripts/compose-source-maps.js"
if [[ -z "$BUNDLE_CONFIG" ]]; then
CONFIG_ARG=""
else
CONFIG_ARG="--config $BUNDLE_CONFIG"
fi
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
BUNDLE_FILE="$CONFIGURATION_BUILD_DIR/main.jsbundle"
EXTRA_ARGS=
case "$PLATFORM_NAME" in
"macosx")
BUNDLE_PLATFORM="macos"
;;
*)
BUNDLE_PLATFORM="ios"
;;
esac
EMIT_SOURCEMAP=
if [[ ! -z "$SOURCEMAP_FILE" ]]; then
EMIT_SOURCEMAP=true
fi
PACKAGER_SOURCEMAP_FILE=
if [[ $EMIT_SOURCEMAP == true ]]; then
if [[ $USE_HERMES == true ]]; then
PACKAGER_SOURCEMAP_FILE="$CONFIGURATION_BUILD_DIR/$(basename $SOURCEMAP_FILE)"
else
PACKAGER_SOURCEMAP_FILE="$SOURCEMAP_FILE"
fi
EXTRA_ARGS="$EXTRA_ARGS --sourcemap-output $PACKAGER_SOURCEMAP_FILE"
fi
# Hermes doesn't require JS minification.
if [[ $USE_HERMES == true && $DEV == false ]]; then
EXTRA_ARGS="$EXTRA_ARGS --minify false"
fi
"$NODE_BINARY" $NODE_ARGS "$CLI_PATH" $BUNDLE_COMMAND \
$CONFIG_ARG \
--entry-file "$ENTRY_FILE" \
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
--platform "$BUNDLE_PLATFORM" \
--dev $DEV \
--reset-cache \
--bundle-output "$BUNDLE_FILE" \
--assets-dest "$DEST" \
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
$EXTRA_ARGS \
$EXTRA_PACKAGER_ARGS
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
if [[ $USE_HERMES != true ]]; then
cp "$BUNDLE_FILE" "$DEST/"
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
BUNDLE_FILE="$DEST/main.jsbundle"
else
EXTRA_COMPILER_ARGS=
if [[ $DEV == true ]]; then
EXTRA_COMPILER_ARGS=-Og
else
EXTRA_COMPILER_ARGS=-O
fi
if [[ $EMIT_SOURCEMAP == true ]]; then
EXTRA_COMPILER_ARGS="$EXTRA_COMPILER_ARGS -output-source-map"
fi
"$HERMES_CLI_PATH" -emit-binary $EXTRA_COMPILER_ARGS -out "$DEST/main.jsbundle" "$BUNDLE_FILE"
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
if [[ $EMIT_SOURCEMAP == true ]]; then
feat: Enable Hermes to work on iOS (#29914) Summary: This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet. Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0) Fixes https://github.com/facebook/react-native/issues/28810 (as above) Checklist: - [x] Adjust release scripts to create Hermes bytecode bundle - [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project) - [x] Test on a new React Native application in both Debug and Release (Device) - [x] Test on an RNTester application in both Debug and Release (Device) - [x] Add missing `i386` to Hermes framework and enable Bitcode - [x] Inspect CI failures for possible regressions - [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810 - [x] Release new Hermes and test against it that everything works ## Changelog [IOS] [FEATURE] - Enable Hermes on iOS [INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues [INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI [INTERNAL] - Fix building RNTester in Release mode [INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!` [INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI [INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway Pull Request resolved: https://github.com/facebook/react-native/pull/29914 Test Plan: Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now. Preview: (note "Engine: Hermes") <img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png"> Reviewed By: hramos Differential Revision: D24684845 Pulled By: cpojer fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
2020-11-03 12:13:01 +03:00
HBC_SOURCEMAP_FILE="$BUNDLE_FILE.map"
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
"$NODE_BINARY" "$COMPOSE_SOURCEMAP_PATH" "$PACKAGER_SOURCEMAP_FILE" "$HBC_SOURCEMAP_FILE" -o "$SOURCEMAP_FILE"
fi
feat: Enable Hermes to work on iOS (#29914) Summary: This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet. Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0) Fixes https://github.com/facebook/react-native/issues/28810 (as above) Checklist: - [x] Adjust release scripts to create Hermes bytecode bundle - [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project) - [x] Test on a new React Native application in both Debug and Release (Device) - [x] Test on an RNTester application in both Debug and Release (Device) - [x] Add missing `i386` to Hermes framework and enable Bitcode - [x] Inspect CI failures for possible regressions - [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810 - [x] Release new Hermes and test against it that everything works ## Changelog [IOS] [FEATURE] - Enable Hermes on iOS [INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues [INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI [INTERNAL] - Fix building RNTester in Release mode [INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!` [INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI [INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway Pull Request resolved: https://github.com/facebook/react-native/pull/29914 Test Plan: Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now. Preview: (note "Engine: Hermes") <img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png"> Reviewed By: hramos Differential Revision: D24684845 Pulled By: cpojer fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
2020-11-03 12:13:01 +03:00
BUNDLE_FILE="$DEST/main.jsbundle"
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
fi
if [[ $DEV != true && ! -f "$BUNDLE_FILE" ]]; then
echo "error: File $BUNDLE_FILE does not exist. This must be a bug with" >&2
echo "React Native, please report it here: https://github.com/facebook/react-native/issues"
exit 2
fi