4 ms·

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

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.

392 3y ago
Could write them for Buck2 and avoid the old bazelisms. But already need a jvm I guess so bazel is no harm.
- bartekpacia 3y ago
  What do you mean by bazelisms? Is it akin to bashisms? :-)
bartekpacia 3y ago
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 https://github.com/MobileNativeFoundation/rules_xcodeproj [1]: https://github.com/cbracken/rules_dart https://github.com/cbracken/rules_dart [2]: https://github.com/matanlurey/rules_dart https://github.com/matanlurey/rules_dart [3]: https://github.com/flutter/flutter/tree/master/packages/flutter_tools https://github.com/flutter/flutter/tree/master/packages/flut...
- eseidel 2y ago
  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.
- malkia 3y ago
  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.
kylegalbraith 3y ago
Just curious if you thought of other build systems outside of Bazel and if so which ones & why?

392 3y ago

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

bartekpacia 3y ago
What do you mean by bazelisms? Is it akin to bashisms? :-)

bartekpacia 3y ago

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 https://github.com/MobileNativeFoundation/rules_xcodeproj [1]: https://github.com/cbracken/rules_dart https://github.com/cbracken/rules_dart [2]: https://github.com/matanlurey/rules_dart https://github.com/matanlurey/rules_dart [3]: https://github.com/flutter/flutter/tree/master/packages/flutter_tools https://github.com/flutter/flutter/tree/master/packages/flut...

eseidel 2y ago
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.
malkia 3y ago
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.

kylegalbraith 3y ago

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