[fishywang]

I hope this will change Jetbrain's attitude towards supporting Kotlin Android rules in Bazel (or anything other than gradle). Last time I asked, they are not very interested[1].

[1] https://discuss.kotlinlang.org/t/android-support-in-kotlinc-...

[vorg]

Don't forget you can use Kotlin to write your build files for Gradle (since Gradle 3.0 was released almost a year ago) which Android Studio auto-completes 100% of the time (rather than 80% of the time as with Apache Groovy). Gradle 3.0 also switched to Kotlin as its "preferred" language for writing addins, so conceivably you could use the Kotlin language for everything in the Android build chain.

[ZoFreX]

Huh, that's a really useful tip, thank you.

[fishywang]

How would this help people who wants to use Bazel or any other build system other than Gradle?

[pjmlp]

For better or worse, Gradle is the official Android build tool, so why spend resources in something else?

[kuschku]

Because Bazel produces faster, reproducible builds, and can far better combine native and JVM code.

It’s a huge improvement.

[pjmlp]

But isn't part of the Android SDK, Gradle is.

As I learned through the years, anyone that decides to step outside the SDK tooling accepts the lack of productivity that entails the extra work, making the unofficial tools fit into the SDK expectations.

So why should JetBrains spend development resources (work time * salary / hour) into something that isn't a standard tool just to get brownie points?

[kuschku]

Because Bazel is partially already supported. Google uses it internally a lot, and a lot of the Android buildfiles have been / are being migrated step by step either from Make to Ninja, or from Make to Bazel, long term.