4 ms·
Hmm, you probably have more direct experience; I can only speak to my personal experience which is that biggish Gradle projects are generally broken. Specifical
by iainmerrick 3y ago
Hmm, you probably have more direct experience; I can only speak to my personal experience which is that biggish Gradle projects are generally broken. Specifically at the last, let's see, three Android jobs I've had.
It also seems very, very slow. A trivial wizard-generated app in Android Studio takes significant time to set up and build, for no good reason that I can see. Builds where nothing has changed take time -- it spends many seconds just parsing the build files.
I've tried Bazel and it's both faster and infinitely more robust. I really wish Google had adopted that instead of Gradle for Android Studio.
In a personal project I use Ninja build files generated by hand-rolled Python scripts and that's much, much faster than Gradle. Plenty robust for my purposes and I'm not afraid of clean builds because it's fast.
Not sure what general lesson I should take away, except that Gradle is bad and I don't like it!
I suppose it could be one of those things where you need to learn it properly to appreciate it fully, but the more Gradle I learn the less I like it. Trying to do any kind of custom code generation is really painful, for example.
Edit to add: despite all my whining, I would still use Gradle for a new Android project just because the official tooling support trumps everything else. I definitely wouldn't want to use it outside of Android.
- mike_hearn 3y agoThe first run is very slow yes for a variety of reasons. It should only re-configure if you change the build scripts. It's possible that the Android plugin breaks that property in some way; as I said, it's way too easy to do that. Bazel has been around for years but never managed to displace Gradle, even in Google's own platforms. It's designed for a very specific corporate environment in which policy constrains the way you write software to a tremendous degree. If you match those policies it's great. If you don't then you'll quickly find cases where stuff is easy with Gradle and harder with Bazel. For example, for the longest time even pulling deps from Maven Central took extra third party rules (probably fixed now?), but it's reflective of the mentality.
- jvolkman 3y ago> For example, for the longest time even pulling deps from Maven Central took extra third party rules (probably fixed now?), but it's reflective of the mentality. This seems like a feature to me. Bazel is a generic, extensible build tool; the core project shouldn't need to know the specifics of one dependency system for one language. With recent versions of Bazel and its new module system (bzlmod), it's much easier to pull in third party rules. In this case, just one line: bazel_dep(name = "rules_jvm_external", version = "5.3") https://registry.bazel.build/modules/rules_jvm_external https://registry.bazel.build/modules/rules_jvm_external
- mike_hearn 3y agoIt has rules for C++ and Java apps out of the box, iirc? I'm all for clean layering but that's not an excuse for poor usability. Good to hear that they got it fixed though, last time I looked Bazel had poor IntelliJ support but maybe I should check it out again.
- kaba0 3y agoI mean, that’s android that is doing a shitload of stuff. But what other build tool could do the same thing as android does? There are not many contenders, and I don’t think they would fare much better. On the other side of mobile OSs, xcode is definitely not faring better.