Felt should use arm64 dart sdk and arm64 Chromium when on arm Macs #36336
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
Two things that I may need some help with on this PR:
|
lib/web_ui/dev/felt
Outdated
| exit 1 | ||
| fi | ||
|
|
||
| echo "Running felt with prebuilt Dart SDK at ${DART_SDK_DIR}..." |
There was a problem hiding this comment.
nit: for a tool that's used multiple times daily I prefer minimizing the amount of printed stuff when things are running along the happy path. The closer we are to cp the better. We could have a verbose flag that would output more. Perhaps we should also output more when running on LUCI (I believe there's already a flag for that).
lib/web_ui/dev/browser_lock.yaml
Outdated
| Mac: 1046592 | ||
| Mac_Arm: 1046589 | ||
| Win: 1046600 | ||
| version: '107.0' # CIPD tag for the above Build IDs. Normally "ChromeMajorVersion.UploadAttempt". ;) |
There was a problem hiding this comment.
What do you think of introducing a new variant (can be Linux-only for now) for a more recent Chromium? Similar to Mac/Mac_Arm we could have Linux/Linux_Canary. We wanted to be able to run on stable and on the upcoming versions of Chromium for a while now so we could alert the Chromium project about any incoming regressions. That should meet the needs for the WasmGC experiment, or any future features we're experimenting with.
There was a problem hiding this comment.
That won't work with this current setup, because the version number is the same for all platforms. In general, I feel like the definition of one "platform" being ahead version-wise is confusing and counter-intuitive. I think having support for running on non-stable versions is probably a little out of scope for this particular change. I've made a change to push us back to 105.0, which is the stable version of Chrome. I might augment this a bit more for the wasm changes in a subsequent PR, if 107 is still too new by the time I want to merge the wasm harness stuff.
lib/web_ui/dev/build.dart
Outdated
| @@ -91,11 +92,13 @@ class GnPipelineStep extends ProcessStep { | |||
| Future<ProcessManager> createProcess() { | |||
| print('Running gn for $target...'); | |||
| final List<String> gnArgs = <String>[]; | |||
| final bool isMacosArm = ffi.Abi.current() == ffi.Abi.macosArm64; | |||
There was a problem hiding this comment.
Given that this check is performed in several places, should we add a utility boolean isMacosArm instead of importing dart:ffi everywhere?
There was a problem hiding this comment.
Yeah that's a good idea.
|
Gold has detected about 1 new digest(s) on patchset 8. |
|
Gold has detected about 4 new digest(s) on patchset 10. |
|
test-exempt: part of CI That said, this is probably testable if you want to test it anyway. :-) |
This fixes flutter/flutter#110113
Rather than building the dart sdk in a separate step in order to run felt.dart itself, just use the dart sdk prebuilts. Also, the user can just pass in
DART_SDK_DIRas an environment variable if a custom built dart sdk is needed. The prebuilt we actually use now actually matches the architecture of the system, so on an arm Mac we actually use arm64 SDK.This is good, because now we can actually detect whether we are on arm, and download the right version of Chromium for tests. Added a new Chromium browser platform, and bumped all the versions of Chromium to more recent versions. This is also helpful for the upcoming WASM stuff, which requires some bleeding edge features in V8. If this is too new, let me know and we can pull back to an earlier build, and I can push it forward again when all the WASM unit testing stuff is done.
I also added a
FELT_DEBUG=1environment variable that make the felt process itself debuggable and pauses it on start.