You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Need a way to specify --local-engine for locally built engine #1905
I'm using a locally built engine, all flutter commands should pass --local-engine argument or we will got an error : "You must specify --local-engine if you are using a locally built engine."
Found some flutter tools code convert environment variable LOCAL_ENGINE, FLUTTER_ENGINE into --local-engine, --local-engine-src-path in flutter_tools
Should we do the same in setupToolEnv?
I don't have a locally built engine to test this, but if I supply only "--local-engine" it complains about not having the next argument.
Another option if those env settings work, is you could set dart.env in your VS Code User Settings (this would apply to all projects instead of just the one you modified launch.json), like:
Hi, I think the args in launch.json is not passed to some spawn calls, such as:
FlutterDaemon
runFlutterInFolder in sdk.ts
The second option only works for some flutter tools which convert env LOCAL_ENGINE to --local-engine and pass it to flutter.
All flutter commands need --local-engine cmd line argument such as :
flutter doctor --local-engine=host_debug_unopt
And you can test with a simulated locally built engine:
(I am on Windows, and not sure if the steps below works for you)
add a global env var FLUTTER_ENGINE=/some/path/
create an empty dir named out/host_debug_unopt in /some/path/
copy gen_snapshot from dart-sdk/bin/utils to /some/path/out/host_debug_unopt
run flutter doctor and see if you got an error You must specify --local-engine if you are using a locally built engine.
run flutter doctor --local-engine=host_debug_unopt
Ah, I didn't realise it would affect things like the daemon. I don't think globalFlutterArgs is the best place for this, as that would make it completely global (eg. you can't override it per-workspace). I think it would be better handled similar to pubAdditionalArgs but because we can't read config in the debug adapter (at least, we can't when we move it back out of process) we'll need to pass it in.
I haven't tested it yet, but I think something like this may do?
Activity
littlesome commentedon Aug 5, 2019
Found some flutter tools code convert environment variable
LOCAL_ENGINE,FLUTTER_ENGINEinto--local-engine,--local-engine-src-pathin flutter_toolsShould we do the same in setupToolEnv?
DanTup commentedon Aug 5, 2019
I think you should be able to do this by just specifying the
argsin yourlaunch.json:I don't have a locally built engine to test this, but if I supply only "--local-engine" it complains about not having the next argument.
Another option if those env settings work, is you could set
dart.envin your VS Code User Settings (this would apply to all projects instead of just the one you modifiedlaunch.json), like:Do either of these do what you need?
littlesome commentedon Aug 5, 2019
Hi, I think the
argsinlaunch.jsonis not passed to some spawn calls, such as:FlutterDaemonrunFlutterInFolderin sdk.tsThe second option only works for some flutter tools which convert env
LOCAL_ENGINEto --local-engine and pass it to flutter.All flutter commands need
--local-enginecmd line argument such as :And you can test with a simulated locally built engine:
(I am on Windows, and not sure if the steps below works for you)
out/host_debug_unoptin /some/path/gen_snapshotfromdart-sdk/bin/utilsto/some/path/out/host_debug_unoptflutter doctorand see if you got an errorYou must specify --local-engine if you are using a locally built engine.flutter doctor --local-engine=host_debug_unoptDanTup commentedon Aug 5, 2019
Ah, I didn't realise it would affect things like the daemon. I don't think
globalFlutterArgsis the best place for this, as that would make it completely global (eg. you can't override it per-workspace). I think it would be better handled similar topubAdditionalArgsbut because we can't read config in the debug adapter (at least, we can't when we move it back out of process) we'll need to pass it in.I haven't tested it yet, but I think something like this may do?
3186d21