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

Enable fat binaries with arm64 and x86_64 support #505

Merged
merged 3 commits into from
Jul 16, 2020

Conversation

HeyImChris
Copy link

@HeyImChris HeyImChris commented Jul 15, 2020

Please select one of the following

  • I am removing an existing difference between facebook/react-native and microsoft/react-native-macos 👍
  • I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos 👍
  • I am making a fix / change for the macOS implementation of react-native
  • I am making a change required for Microsoft usage of react-native

Summary

This adds support for Apple's ARM based processors on macOS.

To build this locally, one needs to be sure that RNTester-macOS and all dependent libs have the Build Active Architecture Only flag set. Our CI loops set this automatically on every build, so this should start producing fat binaries from CI once we enable the build machines to run Xcode Universal 12.

Test Plan

Tested this by manually setting the build active architecture only flag to NO and transferring the built project to a Silicon machine. It's able to launch and run and the controls appear equally interactive as they do with an x86_64 build on an intel machine.

I then rebuilt for only x86_64 and moved that project to the Silicon machine to check and that fails to launch, verifying we have a separate, working build for arm64 machines.

Microsoft Reviewers: Open in CodeFlow

@HeyImChris HeyImChris requested a review from tom-un July 15, 2020 23:33
@HeyImChris HeyImChris self-assigned this Jul 15, 2020
@pull-bot
Copy link

Messages
📖

📋 Missing Changelog - Can you add a Changelog? To do so, add a "## Changelog" section to your PR description. A changelog entry has the following format: [CATEGORY] [TYPE] - Message.

CATEGORY may be:
  • General
  • macOS
  • iOS
  • Android
  • JavaScript
  • Internal (for changes that do not need to be called out in the release notes)

TYPE may be:

  • Added, for new features.
  • Changed, for changes in existing functionality.
  • Deprecated, for soon-to-be removed features.
  • Removed, for now removed features.
  • Fixed, for any bug fixes.
  • Security, in case of vulnerabilities.

MESSAGE may answer "what and why" on a feature level. Use this to briefly tell React Native users about notable changes.

Generated by 🚫 dangerJS against 99bd50c

@@ -125,6 +125,13 @@ post_install do |installer|
puts ' adding arm64e to ' + config.name
end
end
# TODO(macOS ISS#2323203): the internal Microsoft build pipeline needs macOS arm64 slices

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am definitely very naive about how this stuff is supposed to work, but if someone takes a dependency on react-native they don't necessarily take a dependency on RNTester, right? So how would a fix in RNTester's podfiles cause clients to end up with arm64 slices? Should we be doing this somewhere in the shared libraries instead?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A consumer of the repo will have dependencies on the *.podspec's in this repo. The Podfile in the RNTester folder is only used by the test app here. External repos would have to replicate what the RNTester Podfile is doing if they wanted macOS arm64 fat slices ahead of released Xcode defaults.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this proves out that RN can build fat binaries. A follow up change has to go in to enable that in CI loops and then any consumers could use either the x86_64 bits or the arm64 bits in their project.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But before this week, updating the CI wouldn’t have successful builds for arm64- this is the final evidence that we can in fact run RN on a silicon machine.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And revealed the need to tweak the ss.osx.exclude_files filter in React-Core.podspec which is goodness.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was also a fix earlier this week that we needed just to get Xcode 12 universal building for either architecture in the first place

@tom-un tom-un merged commit 6c83289 into microsoft:master Jul 16, 2020
# TODO(macOS ISS#2323203): the internal Microsoft build pipeline needs macOS arm64 slices
if target.platform_name == :osx
target.build_configurations.each do |config|
(config.build_settings['ARCHS'] ||= ['$(ARCHS_STANDARD)']) << 'arm64'

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may not be necessary. In standard Xcode 12, ARCHS_STANDARD includes arm64. This definitely won't hurt anything though.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I based it off what we did for our CI loops in FluentUI-Apple where we explicitly set the ARCHS to arm64

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

Successfully merging this pull request may close these issues.

5 participants