Repository navigation
Flutter tool should use the correct architecture when "--local-engine" is specified #132162
Description
Activity
I wonder if we should do alternative (1), make the flag required, and remove the logic to guess the host engine? The logic to guess the host engine has never worked quite right, iirc. Engine devs are the main users of these flags, so we should probably also gather thoughts from more engine folks.
Reacted by Matan LureyI'm a fan of alternative (1), though selfishly I'd like the default to still work and ideally be the right default.
After an initial learning curve, I think just specifying both the local engine and the local engine host would be fine.
This is a duplicate of #117412, but I'll close that one since this has more detail and discussion of proposed solution.
alternative 1 sounds best to me.
Cool, if you're OK with it (I want to give @gaaclarke a chance to weigh in since he filed the original issue), I can take a shot!
#117412 is slightly different since I was building for macOS so the argument was
--local-engine=host_debug_unopt_arm64, but the interpretation is--local-engine=host_debug_unoptwhich is clearly wrong and doesn't need the same considerations as when you are cross-compiling.I'm not as concerned about breaking workflows. Unfortunately there is documentation written about how to use a custom engine in flutter, some of it not under our control. So, adding new flags is breaking all of that, which could be just as bad.
Alternative 3 is Matan's proposal without any transition period or temporary flag (imagine me saying "temporary" in a slimy contemptuous way like Alan Rickman). His idea of having a better warning if using mixmatched local and remote engines is a good one and could remedy any place where a change in the default behavior could lead to problems.
Reacted by Matan Lurey- added a commit that references this issue
on Aug 10, 2023 This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Aug 24, 2023
Problem
In 9489009, @zanderso reverted the Flutter engine, which in turn, meant that my engine and framework versions became out of sync locally when working on a branch. This problem was surfaced when using
flutter run(note,flis a local alias for "my checkout of$FRAMEWORK"):After some debugging and help, I learned this can happen when the "host" (read: where
frontend_serveris running)'s SDK is different than the "device" (read: my Pixel 5, in this case). However, it was really difficult for me to fix this until Jonah pointed out the tool is likely always usinghost_debug_unoptwhen--local-engineis provided, and I was buildinghost_debug_unopt_arm64.Proposal
Add a flag,
--local-engine-use-correct-arch(or a better name), that, when set, uses (for example)host_debug_unopt_arm64(in other words, avoids using Rosetta). After a period of time (TBD), we could flip the default and instruct engine developers they should be building and usinghost_debug_unopt_arm64, and eventually remove the flag.Example:
$ fl run \ --local-engine-src-path=$ENGINE \ --local-engine=android_debug_unopt_arm64 \ --local-engine-use-correct-arch \ --enable-impellerAlternatives
--local-engine-host(this doesn't solve the problem of having the correct default)/cc @christopherfujino @jonahwilliams
I'd be happy to contribute a feature or fix once we reach consensus.