-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
[apple] support tvos_sim_arm64 in toolchain #14439
Conversation
This needs to be updated too bazel/src/main/java/com/google/devtools/build/lib/rules/apple/AppleConfiguration.java Lines 233 to 245 in 519cb4c
|
ah yea be sure to grep for all |
@Wyverald This would be really nice to get into 5.0 if we are creating another RC (which is looks like we might be?). |
Updated! Now it just checks for the prefix on all CPUs and chops it off if |
@kaylathar Can we get this reviewed and imported? I think this should be included in 5.0. cc: @Wyverald. |
Unless there's a strong argument that this is crucial, I'm reluctant to cherrypick any non-trivial changes at this point, for fear of delaying the release even further. We can look at cherrypicking this into a 5.1 release after 5.0 gets out. |
@Wyverald This would be really useful for us as we ship AppleTV and Watch apps. iOS and macOS aren't the only M1-compatible platforms. For the watch especially, we've been having problems running it under rosetta. |
This would fall under OS/Xcode support in my mind, which is a key feature of the LTS releases. |
I have concerns on some portions of this change, in particular tvOS related change. The watchOS related change I will review more closely shortly but I have less concern on. The tvOS change adds more technical debt by adding an additional "sim" CPU as we are moving to platforms and will require internal changes in some cases as well. I will evaluate more fully later today though. |
@kaylathar I can break these up into two PRs if need be. The watch integration is more pressing for us in the short term as the TV app can be built for intel and run under rosetta in the simulator. We're having problems doing that for the watch app. |
It seems to me that this tech debt is pretty localized, and users don't have another option if they need to build for this simulator in the meantime. So can we land that piece as well knowing it's something we'll have to cleanup when the ideal way to implement this lands? I think the worst case scenario here is the ideal solution continues to lag and folks are blocked in the meantime |
The watch-only changes from bazelbuild#14439 Closes bazelbuild#14512. PiperOrigin-RevId: 420296580 (cherry picked from commit b341802)
The watch-only changes from #14439 Closes #14512. PiperOrigin-RevId: 420296580 (cherry picked from commit b341802) Co-authored-by: Dan Fleming <[email protected]>
@kaylathar is there any reference material coming up on how the architectures map differently for platforms? For example, what about I'm interested both to understand your intentions but also to support the possibility of collaborative improvements. i.e. if you're working with a fixed assumption of what the platforms API can support, possibly at the expense of a clean Apple API, my team might be able to find optimizations to support cleaner Apple APIs. I understand Apple rules particularly struggle with their complex configuration needs. |
src/main/java/com/google/devtools/build/lib/rules/apple/AppleConfiguration.java
Outdated
Show resolved
Hide resolved
e4f89f4
to
ad4b87d
Compare
@kaylathar Updated this old PR to fix the conflicts. Still think |
LGTM - I'm fine landing this change given the time it's going to take to get platforms functional. |
@bazel-io flag |
@bazel-io fork 5.1 |
Closes bazelbuild#14439. PiperOrigin-RevId: 427721738 (cherry picked from commit 207c31b)
Closes #14439. PiperOrigin-RevId: 427721738 (cherry picked from commit 207c31b) Co-authored-by: Dan Fleming <[email protected]>
No description provided.