Closed jslater89 closed 2 years ago
I've started on getting the engine builds working again at github.com/jslater89/flutter-rs-engine-builds. None of the three work right now:
That would be absolutely thrilling! If you manage to get the build working, we could create a go-flutter-desktop/engine repo where you will be the owner.
I think the build environment changed somewhat since the last time the flutter-rs engine builds were maintained. I have the Linux build working, but MacOS and Windows are both going to be challenging for disk space reasons. On my local (Linux) machine, the flutter engine directory is almost 30 gigabytes after a build against about 15gb free on the runner instances, and much less ink has been spilled about how to find free space on MacOS and Windows runners than on Ubuntu ones.
A good first step would probably be getting the automatic Linux build working again, and using the scripts for that to provide a manual solution for MacOS/Windows, until such time as someone can solve those problems (or Github gets more generous with the disk space on the runners).
Can't you use a shallow clone? That should greatly reduce the disk usage.
That's a good start—I didn't realize gclient sync had a shallow checkout option until I dug into the documentation this morning. It saved about 12gb—a lot of the dependencies seem to have used shallow checkout already.
Between that and aggressive pruning of unused dependencies for desktop platforms, I have a source checkout down to a little under 11gb, and I think that plus the build artifacts should fit into the other runners, depending on how big the extra Windows dependencies are.
Apparently the Windows runner divides its free space into two partitions, so that one needs some additional work to see if there are things that can be deleted, or if it's possible to pack the build in on a different partition.
I ran a successful Mac profile build just now, however, so that's two of three platforms figured out.
Turns out the Windows runner has 12gb or so free on the D drive, which hosts the default working directory... and 80gb free on the C drive. Hopefully the artifact uploader can handle absolute paths—if so, that's all three platforms figured out.
@pchampio I'll happily contribute the work, if you want to make a repository to host it.
@jslater89 I've sent you an invitation on https://github.com/go-flutter-desktop/engine-builds/invitations !
Nice work @jslater89 ! Don't forget to send a PR on hover to to match so that we have the correct downloads links. ;)
About the number of builds, I'll like to keep the number of github release down so that we don't hit github limit too fast. How about keeping all beta/stables engine builds, and the master builds in between the "to-be" beta tags and the last beta tag? Our github action will need to remove the old builds.
PR inbound!
Releases are a tricky one. The action should only ever create one release per engine commit hash, so it's not as profligate as it seems running twice a day. The difficulty in pruning engines built from one branch but not the other is that engine commit hashes may originate in master, then eventually show up in beta or stable, so there would be some cross-checking to do to make sure we aren't accidentally whacking versions that we want to archive.
I'm also not currently building engines off of stable—there are some differences in the options accepted by the Dart SDK tools between stable and the other branches. I figured that would be acceptable, since the go-flutter-desktop readme says the project tries to stay compatible with beta. I'll turn stable builds back on after the next stable Flutter release, and hopefully they'll just work.
Flutter-rs-engine disabled auto build half years old.
I trial hover build --docker (flutter 2.5) had error "AOT ERROR" #568
@niuhuan @jslater89 is doing an awesome work on this.
Please update hover: https://github.com/go-flutter-desktop/hover#install (version v0.47.0
)
@niuhuan Currently, the only channels and versions that will work are the most recent versions on Flutter beta, dev, and master. Stable will definitely be available again after the next Flutter stable release, and may be available before then.
Stable builds are back for Flutter 2.8, and dev builds are now disabled (as Flutter is winding down the dev channel).
I'm willing to do some legwork to help solve this, but I'm not sure what the best way of doing so would be.