Add a simpler way to use a local Flutter engine #225
Conversation
Rewrites the core logic in Dart, changing the existing scripts to call through to the Dart version. Adds support for an engine_override file that will cause the 'flutter build bundle' to be run with --local-engine.
|
Let me know if you'd prefer having the first commit here (converting |
|
When I did this I also had to modify the Xcode projects to look in my override location for frameworks (i.e. I had to override the framework paths setting in the project). Does this approach avoid the need for that? |
|
Yes, with this approach So for instance, in the example app Xcode runs (In practice, I was doing a manual version of this—leaving the hash unchanged so it wouldn't re-download and stomp my copied version—rather than adjusting paths in the project, but it was somewhat error-prone.) This is more inefficient than modifying the project (extra copy operations, an extra download of the prebuilt version when it's turned back off), but it's very simple to use, and it works exactly the same way regardless of platform or build system (which in turn makes it easy to document). |
franciscojma86
left a comment
franciscojma86
left a comment
There was a problem hiding this comment.
LGTM, one small question.
| It may be useful for debugging or development to run with a [locally built | ||
| Flutter engine](https://github.com/flutter/flutter/wiki/Compiling-the-engine). | ||
| To temporarily override the normal behavior of `update_flutter_engine` and | ||
| `build_flutter_assets`, add a file called `engine_override` at the root of |
There was a problem hiding this comment.
Just curious, why isn't this like .flutter_location_config? Passing the path to the engine as opposed to be forced to checkout the engine in a specific place?
There was a problem hiding this comment.
Just a benefit/effort tradeoff. .flutter_location_config allows for greater flexibility in the regular build environment, where there can be other constraints on the relative location of dependencies, whereas using engine_override is only meant for temporary local use (if a project wants to use a custom engine as a standard behavior, they just shouldn't use update_flutter_engine in their build for instance). So I think that where the engine checkout is located is much less likely to be an issue—especially since the Engine build docs themselves recommend using a folder called engine next to the Flutter tree.
Given that, writing the path configuration in Dart (making sure it handled relative paths, absolute paths, ~/..., etc.) and testing all the variations didn't seem worth the investment of time at the moment.
If someone ends up needing that configurability, patches welcome at that point :)
There was a problem hiding this comment.
Makes sense, thanks!
3 participants
update_flutter_engine and build_flutter_assets now check for an
engine_override file at the root of the repository to trigger the
use of a local engine. Updates the README to link to instructions
on using it.
Since this adds more logic to build_flutter_assets, it has been
rewritten in Dart.
There are some obvious limitations (e.g., hard-coded name/location
requirement, copying every time instead of only when the
local build has changed), which can be addressed in the future if
there's sufficient demand. Since it is only intended for temporary use
when debugging, or testing engine changes, this may be sufficient,
and is a significant improvement over managing it manually.
Unlike .flutter_location_config this has no leading ., and is in the
repository rather than above it. This difference is intentional,
since unlike .flutter_location_config this is for temporary use,
so having it show up in directory listings and git status is
helpful as a reminder that it is enabled.
Fixes #160