tools: Support --host-arch option in flutter precache - #190480
Conversation
There was a problem hiding this comment.
Code Review
This pull request adds a --host-arch option to the precache command and introduces a FLUTTER_HOST_ARCH environment variable override to allow overriding the host platform architecture. The review feedback suggests refactoring _MacOSUtils.hostPlatform to delegate to super.hostPlatform to avoid code duplication, and simplifying the PrecacheCommand constructor and associated tests by removing the redundant os parameter and field.
9fbf0f9 to
ba2d728
Compare
bkonyi
left a comment
There was a problem hiding this comment.
LGTM overall, just a couple of nits.
Adds a `--host-arch=<x64|arm64>` option to `flutter precache` and adds support for the `FLUTTER_HOST_ARCH` environment variable in `OperatingSystemUtils.hostPlatform`. When specified, this overrides the default hardware detection check (`sysctl hw.optional.arm64` on macOS), and causes `flutter precache` to download host engine artifacts for the specified architecture instead. This is required to allow arm64 macOS CI hosts to download and cache x64 host engine artifacts when cross-packaging x64 Flutter SDK release archives on an arm64 host in the `packaging/packaging` recipe in `packaging.py`. See: https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/packaging/packaging.py Issue: flutter#189144
os.dart: OperatingSystemUtils.hostPlatform now owns hostPlatformOverride and the env var precedence logic. precache.dart: Kill the redundant os. precache_test.dart: Simplified the test. os_test.dart: Drop the unused sysctl commands queued in the precendence test since they're not needed.
207047e to
b813e05
Compare
b813e05 to
9bdc48c
Compare
| @@ -217,6 +217,7 @@ class Cache { | |||
| final Platform _platform; | |||
| final FileSystem _fileSystem; | |||
| final OperatingSystemUtils _osUtils; | |||
There was a problem hiding this comment.
Can we not just make _osUtils public?
| if (hostPlatformOverride case final HostPlatform override) { | ||
| return override; | ||
| } | ||
| if (_platform.environment['FLUTTER_HOST_ARCH'] case final String overrideArch) { |
There was a problem hiding this comment.
A+, no notes. Just an informative "if you ever want to use multiple keys from that map", this pattern works:
class Platform {
final environment = <String, Object?>{};
}
void main() async {
final _platform = Platform()
..environment['FLUTTER_HOST_ARCH'] = 'arch128'
..environment['FOO'] = 'bar';
if (_platform.environment case {
'FLUTTER_HOST_ARCH': final String overrideArch,
'FOO': final String foo,
}) {
print((overrideArch: overrideArch, foo: foo));
// (foo: bar, overrideArch: arch128)
}
}Adds a `--target_arch=<x64|arm64>` option to
`dev/bots/prepare_package.dart` to support cross-packaging SDK archives
for a target architecture different from the host architecture.
When target arch is specified, we set `FLUTTER_HOST_ARCH` in the
environment of each subprocess spawned by the packaging script. This is
picked up by `update_dart_sdk.sh` and `update_dart_sdk.ps1` when
choosing which Dart SDK to download, and by
`OperatingSystemUtils.hostPlatform` when the tool picks which host
engine artifacts to cache. Those run from `bin/flutter` before the
flutter tool exists, so the environment is the only means we have to
pass this setting.
This patch allows arm64 macOS CI hosts to download and cache x64 host
engine artifacts when cross-packaging x64 Flutter SDK release archives
on an arm64 host (or theoretically vice-versa, but we'll never do that)
in the `packaging/packaging` recipe in `packaging.py`.
It's worth noting that the scripts and tool this drives are the ones in
the branch being packaged, not the ones this script was run from, so
`--target_arch` depends on that branch having cherry-picks to handle
both `FLUTTER_HOST_ARCH` support in
`bin/internal/update_dart_sdk.{sh,ps1}` (flutter#190421) and the `--host-arch`
option of `flutter precache` (flutter#190480).
See: https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/packaging/packaging.py
Issue: flutter#189144
) Adds a `--target_arch=<x64|arm64>` option to `dev/bots/prepare_package.dart` to support cross-packaging SDK archives for a target architecture different from the host architecture. When target arch is specified, we set `FLUTTER_HOST_ARCH` in the environment of each subprocess spawned by the packaging script. This is picked up by `update_dart_sdk.sh` and `update_dart_sdk.ps1` when choosing which Dart SDK to download, and by `OperatingSystemUtils.hostPlatform` when the tool picks which host engine artifacts to cache. Those run from `bin/flutter` before the flutter tool exists, so the environment is the only means we have to pass this setting. This patch allows arm64 macOS CI hosts to download and cache x64 host engine artifacts when cross-packaging x64 Flutter SDK release archives on an arm64 host (or theoretically vice-versa, but we'll never do that) in the `packaging/packaging` recipe in `packaging.py`. It's worth noting that the scripts and tool this drives are the ones in the branch being packaged, not the ones this script was run from, so `--target_arch` depends on that branch having cherry-picks to handle both `FLUTTER_HOST_ARCH` support in `bin/internal/update_dart_sdk.{sh,ps1}` (flutter#190421) and the `--host-arch` option of `flutter precache` (flutter#190480). See: https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/packaging/packaging.py Issue: flutter#189144 <!-- Thanks for filing a pull request! Reviewers are typically assigned within a week of filing a request. To learn more about code review, see our documentation on Tree Hygiene: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md --> ## Pre-launch Checklist - [X] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [X] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [X] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [X] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [X] I signed the [CLA]. - [X] I listed at least one issue that this PR fixes in the description above. - [X] I updated/added relevant documentation (doc comments with `///`). - [X] I added new tests to check the change I am making, or this PR is [test-exempt]. - [X] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [X] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [AI contribution guidelines]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
Adds a
--host-arch=<x64|arm64>option toflutter precacheand adds support for theFLUTTER_HOST_ARCHenvironment variable inOperatingSystemUtils.hostPlatform.When specified, this overrides the default hardware detection check (
sysctl hw.optional.arm64on macOS), and causesflutter precacheto download host engine artifacts for the specified architecture instead.This is required to allow arm64 macOS CI hosts to download and cache x64 host engine artifacts when cross-packaging x64 Flutter SDK release archives on an arm64 host in the
packaging/packagingrecipe inpackaging.py.See: https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/packaging/packaging.py
Issue: #189144
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.