Building from source

[selfisekai]

I think a lot of missed potential in Flutter is suitability to Linux distros: possibility to package Dart and Flutter themself, allowing to package apps created with them. Is this something this project would accept contributions for?

(I'm the maintainer of flutter and dart packages at Alpine Linux)

[matthew-carroll]

We're certainly happy to consider it. We're here to deliver value where the community wants it. The first thing we need to do is get the engine building, uploaded, and delivered through Flock so that we can match baseline Flutter. From there, we'd be happy to see where we can take things.

[RossComputerGuy]

I'm interested in this too, maintainer for Flutter in Nixpkgs. I got the engine building in nix but it's a bit of a pain.

[matthew-carroll]

Can you guys elaborate on what "Build from source" means? If this were implemented, how would it change Flutter? What would it look like to use this capability?

[RossComputerGuy]

The TLDR of it is Flutter fetches many prebuilt components, the engine for instance. These prebuilts can produce impurities in certain environments, especially in the Nix ecosystem.

The other side of it is the engine, the engine uses gclient to fetch the source. The sources contains forks or original sources of libraries and tools packagers and developers already have. They also contain prebuilt binaries. The prebuilt binaries inflates the fetch size and causes issues outside of FHS environments (Nix & likely Guix).

Relying on the developer to install packages which they already will likely have (gtk, clang, ninja, etc) can decrease time to get the source code, reduce the burden of maintaince, and just make the overall experience better.

[RossComputerGuy]

See https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/flutter/engine/source.nix for how I was able to produce a fully pure and reproducible source. As you can see, a lot has to be removed. Hooks have to be disabled in order to not run tools which will fail due to Nix not using FHS.

There's also all of this post unpack work inside the actual engine build:

https://github.com/NixOS/nixpkgs/blob/95c1043ff5531b4348c50fa92763954df98399e/pkgs/development/compilers/flutter/engine/package.nix#L194-L244

It's a lot to maintain but makes it possible. I also recently might've ran into a problem where 3.26 changes something and is producing unreproducible sources which makes fetching the source undeterministic.

[matthew-carroll]

CC @jezell

[selfisekai]

Other problems: the code is open, but it's not at all clear how to put it together, everything just expects other things to be in certain paths. There are URLs to files in GCS buckets, but no documentation on how to build them and what exactly is expected.

Little failures that are hard to debug: my last one was "the Flutter SDK is not available" on every flutter pub get because bin/cache/flutter.version.json was not valid JSON - failing to parse the file was just "fine".

Flutter directory has to be a git repository and user-writable, which is just not how distro packages work.

The flutter package at Alpine Linux has 2208 lines of patches as of now, and the scope is still just Linux desktop builds.

IMO:

• release tarballs with source code for releases (this is how Chromium handled it for years. You can just download https://commondatastorage.googleapis.com/chromium-browser-official/chromium-130.0.6723.69.tar.xz or any other version),
• add build scripts allowing to build and install in correct paths all needed components (framework, tool, engine, whatever else),
• make tool distributable - work outside a git repo, depend on distro-shipped artifacts and/or allow downloading artifacts to user-owned directories,
• allow dynamically linking distro dependencies (like icu, zlib) to engine.

If this were implemented, how would it change Flutter? What would it look like to use this capability?

For a regular Flutter app developer, this would make flutter available as a regular distro package, rather than requiring manual installation, and allow Flutter to work at all in some less typical environments (Alpine is not compatible with the downloaded binaries as they depend on GNU libc, NixOS and Guix were also mentioned above by Ross).

For a regular Linux end user, this would make flutter-based apps available in more distros. I think a good example here is intiface-central, which is fairly known, released under a free license, and supports Linux, but the fact that it's written in Flutter limits it a lot.

[jezell]

I really like the idea of enabling some more customization of the lower level parts of the engine. I had similar challenges making custom canvaskit builds on web. There's a lot of potential to unlock in customizing some of the lower level parts of the engine build. The key thing to figure out is how to do this in a way that doesn't conflict too much with changes that are being auto merged, but what you accomplished there is proof that it can be done.