Don't need all of the stuff they're showing there. Can also structure it in a different way than how the IDE structures it. Can use a single build.gradle without that directory structure. It's really just standard gradle usage, with the Android plugin as the main plugin.
Not clear why I'd prefer bazel to make. Make gives fast incremental builds unless you intentionally misuse it.
-
-
The reason would be that they already wrote all the handling for Android support and they have an IDE plugin so if you ever wanted to open the project in the IDE for static analysis, etc. you could. It also wouldn't drive other contributors away as much.
-
From my perspective (ppl I work with), bazel would drive them away a lot more than make.
-
AOSP still primarily uses make but it's not really intended for external projects. They moved to their own implementation of make on top of ninja for better incremental build performance but it still works with GNU make.
-
They're slowly moving away from using make but not for performance reasons anymore (https://github.com/google/kati solved those). They treat it make as a declarative build system everywhere but central build code which just includes all of the declarative http://Android.mk files.
-
Their new build system is essentially just an implementation of their http://Android.mk templates in a way that enforces they're declarative. It's a little bit faster but the main reason is just avoiding the chance of making mistakes with make somewhere in the source tree.
-
Not sure how hard it would be to do things by hand with make. It would be painful because you would be exposed to the underlying tools changing over time. A year ago, they compiled Java -> dex with jack without javac, but now it's javac for bytecode -> dex compiler.
-
You'd need to manually deal with compiling resources, proguard optimization, bundling it into an apk, signing releases, etc. Tools aren't that hard to use by hand but it would be annoying. If someone wrote an equivalent to AOSP make support for standalone apps it'd be fine.
-
Personally prefer http://Android.mk (old) / Android.bp (new) over build.gradle and prefer the simpler AOSP style directory structure with src/ and res/ at the top-level. Wouldn't want to lose IDE support despite writing everything in Vim though.
- 6 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.