-
Notifications
You must be signed in to change notification settings - Fork 28.7k
Fix --local-engine for the new web/wasm mode #113759
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
da9962b
Fix --local-engine for the new web wasm mode
mdebbar 69410f6
fix libraries.json
mdebbar 7867498
flip the order of lookup for dart sdk
mdebbar 29a0042
Merge branch 'main' into flutter_tool_wasm
mdebbar 2f307c9
minor change
mdebbar d8bdc9c
add tests
mdebbar 5f102bb
remove prints
mdebbar d4b5d6a
fix analyzer error
mdebbar File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A use case that we should retain is using the
flutter
tool to drive a local engine build that has a modified Dart SDK. For example, imagine that a developer wants to use theflutter
tool to drive an engine that has local modifications todart2wasm
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should introduce a flag for this use case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hold on. Maybe we should reverse the lookup order? So we check for a dart sdk inside the out folder. If we can't find it, we look in the prebuilts folder. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I might have been unclear. I think instead of this PR, the engine build should populate the directory that the tool is currently looking in.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The output of the new
--web
build is platform-independent. We can build/zip it once then use the same on linux, mac and windows machines (in CI, for example).Given that prebuilt dart sdks are platform-dependent, I'm not sure how we could do this while preserving the platform-independency of the build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that makes sense. I guess the way it'd have to work is that if you say
--no-prebuilt-dart-sdk
for the--web
build, you'd build the Dart SDK with the default host toolchain.Maybe the way forward here is to file an issue for that, and for now reverse the lookup order as you suggest. I'd also like to know if @jonahwilliams sees any issues with that approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good! I created an issue: #113772 and reversed the lookup order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I strongly believe we should be rethinking this idea in general, at least for the web build if not more broadly. The
--no-prebuilt-dart-sdk
flag really complicates our build process and I think we should in general be moving away from it. Supporting both paths makes things very complicated.In the web case, it is weird to put native host artifacts such as the dart sdk inside of the wasm output directory. There are ways of invoking the host toolchain from the wasm build if we want, but I question whether this is really worth the effort to support this mode. More broadly, it feels wrong for the dart sdk to be an actual output of the flutter engine build, even in the native case.
Editing code in
third_party/dart
inside the engine repo doesn't really feel like a great workflow to me personally, I'm not sure how many people rely on this. If someone is making changes to the dart sdk, I expect that they should have the dart sdk repo itself already checked out and are able to build using the normal build process for the dart sdk. If anything we should probably add support for using an arbitrary built dart sdk instead of coupling that to the engine build.I'm not sure what the best long-term plan here is, but I think the main reason we expect the dart sdk to be in the engine build directory is for historical reasons before we were mostly using the sdk prebuilts. This might be a good opportunity to think about how these dependencies work and seeing if we can improve this process.