Hacker News Reader

Comment by bartekpacia | Hacker News Reader

I feel like the build system situation in Flutter is really unfortunate. For Android there's Gradle, for iOS/macOS there's Xcode (xcodebuild), CMake for Linux, some Visual Studio-something for Windows and so on. This causes problems at scale – reliable, incremental, cross-platform builds are very hard/impossible. Same goes for splitting the build work across multiple workers (aka remote build execution). I did some research on this and looks like Bazel is the tool designed to solve this kind of problems. Of course the cost of Bazel adoption is huge but at a certain scale it makes a lot of sense. As the number of huge Flutter codebases grows I think this problem will become more pervasive.

I read on flutter/flutter repo that Google has Bazel rules for Flutter, but they're internal and they're not interested in open-sourcing them.

View on HN

I agree 100%. Flutter needs a real build system. Bazel could be that? Feels better than inventing a new one.

Google has Flutter and Dart rules, yes, but they were started so long ago (for Google AdWords, which uses Dart on the Web), and historically were very tied to internal Google oddities. If we went with Bazel, we'd just write new ones publicly.

Could write them for Buck2 and avoid the old bazelisms. But already need a jvm I guess so bazel is no harm.

What do you mean by bazelisms? Is it akin to bashisms? :-)

Yes, IMHO the world doesn't need another build system. Bazel sounds great, and the mobile development community seems to be converging arond it as the go-to tool for huge apps, e.g. see rules_xcodeproj [0].

It'd be a lot of work, because no good Bazel rules for Dart exist (there is [0] which is old and unmaintained, although it was recently forked [2] by a Google engineer working on Flutter), and of course, no rules for Flutter exist as well. Another problem here is that a lot of flutter_tools [3] code assumes that Android project uses Gradle, and iOS project uses Xcode.

After some investigation, it looks that to change this situation one could either:

(1) reimplement flutter_tools in Bazel, or

(2a) contribute to flutter_tools to work with Bazel, or

(2b) fork flutter_tools to work with Bazel (like you forked the engine)

Each of these is quite a lot of work. I'm curious to hear what you think about this.

[0]: https://github.com/MobileNativeFoundation/rules_xcodeproj

[1]: https://github.com/cbracken/rules_dart

[2]: https://github.com/matanlurey/rules_dart

[3]: https://github.com/flutter/flutter/tree/master/packages/flut...

Fuchsia also has rules for flutter, though in GN - but it's closer to bazel than the rest. Also I think their "sdk" (for consuming) is using bazel.

I'd probably start simpler. I'd just start with either cbracken or matan's rules and see if I could get some basic Flutter projects building nicely with Bazel. Then I'd look to see how it would make sense to integrate with Flutter tools.

I think there are still open questions as to what kinds of projects would want to use bazel. And if they do use bazel, what do they do for all the other services flutter_tools currently provides (like running on a device)? Inside Google they have different (bazel-specific) implementations for "run this app on an android device" so they don't use the `flutter` tool internally I don't think. I do think some of the internal bazel rules might call into `flutter` though? I'm not sure. Those are all question's I'd explore after having some working examples that I could stare at and decide if I liked the DX of them before proceeding further.

Just curious if you thought of other build systems outside of Bazel and if so which ones & why?

Reply on news.ycombinator.com