Gradle
-
Who the hell at Google decided that using this sorry excuse for a build system was suitable for Android developing, and why the hell so?
Such slow and buggy crap! No one I know working as a programmer, besides Android developers, have to put up with so much bullshit from a single product, so many hours of the day.
-
PRs are accepted.
It's no slower than any other build system, and I've never encountered a single bug with it. Have you got any, you know, specific issues?
-
Welcome to java build tools where for some reason everyone thought bash scripts were a bad idea and then proceeded to re-implement them badly.
-
I used it for most of 6 years at my last job with no major problems. Not Android though. I do seem to remember the Android build stuff being a bit odd.
-
No one I know working as a programmer
ā¦ except all the Java ones.
See, Gradle is a massive improvement over Maven. Yes, it is a massive improvement mainly because Maven set the bar so low it came out through the ground Down Under, but it is an improvement and if they were willing to put up with that, there is no reason they shouldn't be willing to put up with this.
And for native development, the house of
cardsmakefiles shipped with the NDK was so fragile that it was almost unworkable as well. Fortunately they've added support for CMake now (back when I worked on Android, I wrote that for our project myself, including calling ant from it, so it was all cmake like the other platforms).Unfortunately the overall state of build systems is pretty bad all around. If you target specific platform and work with one language, there is usually some usable tool (except for Java; see above), but if you need multi-platform and mixing languages, it's quite poor.
@pie_flavor said in Gradle:
PRs are accepted.
Unfortunately it'd probably need quite a big redesign.
@pie_flavor said in Gradle:
It's no slower than any other build system
Yes, it is. Loading the script and all the plugins takes awfully long. It is still better than Maven, but see above.
A good build system can check whether anything needs to be rebuilt in tenth of a second where Gradle tends to need half a minute for even small project. They worked around it by keeping a long running process, but
Ā¹.@mikehurley said in Gradle:
I do seem to remember the Android build stuff being a bit odd.
It's much less odd now with Gradle, actually. The reason here is that you build multiple versions of native libraries if you have those and then you transpile the Java classes into another format, so the build is quite a few more steps then typical. Shows well how poor the build systemsāmost of themāare at building actually complex stuff.
-
No one I know working as a programmer
ā¦ except all the Java ones.
See, Gradle is a massive improvement over Maven. Yes, it is a massive improvement mainly because Maven set the bar so low it came out through the ground Down Under, but it is an improvement and if they were willing to put up with that, there is no reason they shouldn't be willing to put up with this.
And for native development, the house of
cardsmakefiles shipped with the NDK was so fragile that it was almost unworkable as well. Fortunately they've added support for CMake now (back when I worked on Android, I wrote that for our project myself, including calling ant from it, so it was all cmake like the other platforms).Unfortunately the overall state of build systems is pretty bad all around. If you target specific platform and work with one language, there is usually some usable tool (except for Java; see above), but if you need multi-platform and mixing languages, it's quite poor.
@pie_flavor said in Gradle:
PRs are accepted.
Unfortunately it'd probably need quite a big redesign.
@pie_flavor said in Gradle:
It's no slower than any other build system
Yes, it is. Loading the script and all the plugins takes awfully long. It is still better than Maven, but see above.
A good build system can check whether anything needs to be rebuilt in tenth of a second where Gradle tends to need half a minute for even small project. They worked around it by keeping a long running process, but
Ā¹.@mikehurley said in Gradle:
I do seem to remember the Android build stuff being a bit odd.
It's much less odd now with Gradle, actually. The reason here is that you build multiple versions of native libraries if you have those and then you transpile the Java classes into another format, so the build is quite a few more steps then typical. Shows well how poor the build systemsāmost of themāare at building actually complex stuff.
If Android is doing shenanigans like building JVM class files and then translating those to another language, it seems reasonable to me that the build process is more complex. More steps, more complex. Not sure what you'd expect it to do differently. And whatever it would do differently would probably be an Android tooling thing, not a gradle thing. Now if you're building a regular java or scala app, gradle works just fine.
-
@Bulb e no repro. Gradle runs immediately for me. Although maybe there's some special Android screwery to blame - I use it for regular Java projects, not Android.
-
@pie_flavor said in Gradle:
@Bulb e no repro. Gradle runs immediately for me. Although maybe there's some special Android screwery to blame - I use it for regular Java projects, not Android.
I'm also assuming he's past the bootstrapping phase where the gradle scripts are downloading gradle itself. That can take a while on a new dev box or build machine. But not that bad.
-
@pie_flavor said in Gradle:
I've never encountered a single bug with it
@pie_flavor said in Gradle:
Gradle runs immediately for me
See: Earth-73.
-
Unfortunately the overall state of build systems is pretty bad all around.
^This.
@pie_flavor said in Gradle:
It's no slower than any other build system
Yes, it is. Loading the script and all the plugins takes awfully long. It is still better than Maven, but see above.
A good build system can check whether anything needs to be rebuilt in tenth of a second where Gradle tends to need half a minute for even small project.
OTOH, Gradle seems to be the only build system in which maintaining complex builds is not a complete nightmare. I'd definitely prefer having a slow, multi-project Gradle build instead of dozens of Bash scripts and 15 different Makefiles.
Gradle is an enterprise-y tool that eats 8GB of RAM for breakfast. But it's also easy to extend, has an integrated scripting language that doesn't suck and a sane DSL for configuring your build. If you're working on a small pet project, you'll probably hate it because of its resource usage, but once you've seen the alternatives for big, complex projects, you'll learn to appreciate it.
-
OTOH, Gradle seems to be the only build system in which maintaining complex builds is not a complete nightmare. I'd definitely prefer having a slow, multi-project Gradle build instead of dozens of Bash scripts and 15 different Makefiles.
That seems like a pretty low bar. The only time I've seen Makefiles is on venerable old C/C++ library code.
-
That seems like a pretty low bar. The only time I've seen Makefiles is on venerable old C/C++ library code.
Please tell me you're hiring.
Also, Groovy and Kotlin are about 1000x better and more readable than that God-awful macro language CMake uses.
-
@mikehurley said in Gradle:
If Android is doing shenanigans like building JVM class files and then translating those to another language, it seems reasonable to me that the build process is more complex. More steps, more complex.
The problem is not that it is more complex, but that the build systems are not really up to handling it well. In C++ land there is the tradition of fine-grained tracking of dependencies and the build systems have core engines for that and only start the components for the actual work if they are needed. But in Java land it isn't there (the compiler needs to load all sources of each component even if they didn't change, but there is still inter-module dependencies to track), so everything gets loaded and every plugin checks the dependencies itself and it tends to be either inefficient or unreliable depending on the plugin (it's pretty tricky; even the C++ engines are not always quite reliable).
@mikehurley said in Gradle:
Not sure what you'd expect it to do differently.
I expect a properly layered build system that has a fast and reliable dependency resolution engine.
@pie_flavor said in Gradle:
Gradle runs immediately for me.
You probably have the service running. All IDEs start it these days. It's their workaround for the slow start-up.
I'd definitely prefer having a slow, multi-project Gradle build instead of dozens of Bash scripts and 15 different Makefiles.
Make has it's own problems. Mainly the heaps of implicit rules nobody ever uses and all the half-baked features developed only to barely useful state. It is, however, much simpler. Once you learn it, you can automate almost anything with it. In Gradle the actual build logic is spread over dozens of plugins, so for every use-case you have to learn another component. When they fit together well, it's easier, but when they don't, it's harder to fix.
Also, Groovy and Kotlin are about 1000x better and more readable than that God-awful macro language CMake uses.
Yeah, CMake is an ugly hack and it's custom language is brain-damaged. It does do one thing right though: it only executes the script when it changed and generates the build steps from it to be executed separately, which saves time and resources.
-
Make has it's own problems. [...] It is, however, much simpler. Once you learn it, you can automate almost anything with it. In Gradle the actual build logic is spread over dozens of plugins, so for every use-case you have to learn another component.
That's not my experience. I'd say that the core concepts of Gradle (tasks, task graph, configurations, etc.) are also quite simple. Plugins are just fancy task generators that let you specify a high-level model of the build instead of writing the tasks yourself.
When they fit together well, it's easier, but when they don't, it's harder to fix.
If two plugins interact badly, then one of them is badly written. Which doesn't help you as the user, but at least Gradle makes it somewhat easy to debug the build and figure out what went wrong.
-
Welcome to
javabuild tools where for some reason everyone thought bash scripts were a bad idea and then proceeded to re-implement them badly.FTFY
-
The problem is not that it is more complex, but that the build systems are not really up to handling it well. In C++ land there is the tradition of fine-grained tracking of dependencies and the build systems have core engines for that and only start the components for the actual work if they are needed. But in Java land it isn't there (the compiler needs to load all sources of each component even if they didn't change, but there is still inter-module dependencies to track), so everything gets loaded and every plugin checks the dependencies itself and it tends to be either inefficient or unreliable depending on the plugin (it's pretty tricky; even the C++ engines are not always quite reliable).
Not true at all. Not with Gradle anyway. A build task runs fast but if you run it again it's instant. It does in fact know when files have not been changed, even when I use things like Kotlin or Shadow. Even ForgeGradle, the Great Resource-Hogging Beast of the North, understands changed files vs identical files easy enough. Even when it's one single file that's changed, it only recompiles that one file and leaves the rest alone (since that's basic javac functionality).
-
It is, however, much simpler. Once you learn it, you can automate almost anything with it. In Gradle the actual build logic is spread over dozens of plugins, so for every use-case you have to learn another component.
Not really. You can do all the super basic automation with Gradle too, it's got standard 'copy file' / 'run command' / whatever (you know, being Groovy and all). The plugins are to abstract over it in a simple, repeatable, and manageable system.
-
Yeah, CMake is an ugly hack and it's custom language is brain-damaged. It does do one thing right though: it only executes the script when it changed and generates the build steps from it to be executed separately, which saves time and resources.
That's only really really important when building C++ projects (and it's of quite a bit of interest to C and Obj-C projects too). For a Java project, rebuilding a few thousand source files only takes a few seconds unless you're on a platform with a horribly slow disk. (Yes, really.) C# may be pretty quick too, but I've not tested.
The slow part of building Java projects is usually running any attached test suites; our integration tests take quite a few hours to run in full mode (though that beats taking multiple days, which they used to). Almost none of that runtime is to do with the language the code is written in; the time to move terabytes of data is a bit more criticalā¦
-
It is, however, much simpler.
Unfortunately, make is too simple minded to cope with languages that use a āsimultaneous definitionā rule for everything. Both Java and C# do that, and it's very nice from a programmer's perspective, but it's incompatible with make as it means that there's not a right order for feeding individual source files into the compiler (which compensates by trying to find the source you were talking about). This gets really messy as bits and pieces change under make's feet, so much so that you can end up with failing builds or failures to build everything that needs to be rebuilt.
BTDT. Learnt it all the hard way close to 20 years agoā¦
-
few seconds
The problem here is that few seconds is way too much. For smooth edit-compile-test cycle the build system really needs to stay below about half a second for small (one or two files) edits.
Not like one could get that with C++ anyway, because the link alone usually takes several seconds for anything not completely trivial. Also no way to get it with make because it always tries to look for all those nonexistent sources according to all the implicit rules nobody remembers how to turn off (yes, it can be done and no, I haven't seen anybody actually use them, but no, I haven't seen anybody actually turn them off either).
-
@pie_flavor said in Gradle:
A build task runs fast but if you run it again it's instant.
Well, that was not my experience, but it's been a couple of years, so maybe they improved (they also added the service as a work-around).
-
@pie_flavor said in Gradle:
Not true at all. Not with Gradle anyway. A build task runs fast but if you run it again it's instant. It does in fact know when files have not been changed, even when I use things like Kotlin or Shadow.
In fact, in my experience, Gradle tries to avoid work too much sometimes and computes checksums of literally everything. If you want to cause a lot of unnecessary network traffic and experience a horribly slow build process, try to build a Gradle project on NFS. Even just having your GRADLE_USER_HOME on NFS is generally a bad idea (and it honestly sucks that they didn't think of this use case, since user home directories on NFS are not exactly rare).
-
@pie_flavor said in Gradle:
@Bulb e no repro. Gradle runs immediately for me. Although maybe there's some special Android screwery to blame - I use it for regular Java projects, not Android.
I know IntelliJ/Android Studio's Gradle support for Android used to be extraordinary fragile and easy to fail in Fun and Interesting ways.
No idea if that's still the case, but it definitely was the last time I did Android dev.
-
The problem here is that few seconds is way too much. For smooth edit-compile-test cycle the build system really needs to stay below about half a second for small (one or two files) edits.
I assume that my IDE does this; I've never noticed a problem with Java code in this respect (except when the IDE needs a restart, usually around once a week). A few seconds is fine for a CI flow, as in āfast enough that it causes absolutely nobody any problemsā.
-
A few seconds is fine for a CI flow, as in āfast enough that it causes absolutely nobody any problemsā.
I could see it being a problem for guess-and-test coders: "does it look right now? Now? How about now...?"
-
@pie_flavor said in Gradle:
A build task runs fast but if you run it again it's instant.
Well, that was not my experience, but it's been a couple of years, so maybe they improved (they also added the service as a work-around).
That's not how my Android Studio works either. It takes minutes to build even if you've changed nothing.
From my point of view Gradle is an astonishingly slow build system. I'm used to the speed of GCC with Make. Maybe it's Android Studio using Gradle wrong though, it doesn't do much right as a program...
-
@Cursorkeys said in Gradle:
@pie_flavor said in Gradle:
A build task runs fast but if you run it again it's instant.
Well, that was not my experience, but it's been a couple of years, so maybe they improved (they also added the service as a work-around).
That's not how my Android Studio works either. It takes minutes to build even if you've changed nothing.
From my point of view Gradle is an astonishingly slow build system. I'm used to the speed of GCC with Make. Maybe it's Android Studio using Gradle wrong though, it doesn't do much right as a program...
I've used gradle in IntelliJ (which Android Studio is) for Android and regular apps. There's something hokey with the Android build tools. Gradle/IntelliJ works much more smoothly with regular apps.
-
@mikehurley said in Gradle:
@Cursorkeys said in Gradle:
@pie_flavor said in Gradle:
A build task runs fast but if you run it again it's instant.
Well, that was not my experience, but it's been a couple of years, so maybe they improved (they also added the service as a work-around).
That's not how my Android Studio works either. It takes minutes to build even if you've changed nothing.
From my point of view Gradle is an astonishingly slow build system. I'm used to the speed of GCC with Make. Maybe it's Android Studio using Gradle wrong though, it doesn't do much right as a program...
I've used gradle in IntelliJ (which Android Studio is) for Android and regular apps. There's something hokey with the Android build tools. Gradle/IntelliJ works much more smoothly with regular apps.
That's kinda what I was thinking. I remember a lot of fucking around with config files and error messages that were indecipherable just to get a hello world project building..
-
@Cursorkeys said in Gradle:
I'm used to the speed of GCC with Make.
That comparison is a bit flawed anyway. It's like comparing IRC and NodeBB. Sure, they both let people communicate and one of them is blazingly fast while the other is slow as molasses, but their features are also not quite comparable.
I mean, if make works for you, good for you, but it's a much simpler tool.
-
@Cursorkeys For Flutter the whole things works rather well.
Then again, Flutter has Hot Reload so you rarely completely start a new build when you change code.
-
Gradle is not about speed right now.
Configuration and configuration.all are logically project-wide settings, but they are not compatible with each other.
Therefore, it must be described separately below.configurations {
providedRuntime
}
configurations.all {
resolutionStrategy.cacheChangingModulesFor 0, "seconds"
}The current version is 6.6, but it still looks like this.
-
A few seconds is fine for a CI flow, as in āfast enough that it causes absolutely nobody any problemsā.
I could see it being a problem for guess-and-test coders: "does it look right now? Now? How about now...?"
Devops?
-
@heegu-lee said in Gradle:
Gradle is not about speed right now.
Configuration and configuration.all are logically project-wide settings, but they are not compatible with each other.
Therefore, it must be described separately below.configurations {
providedRuntime
}
configurations.all {
resolutionStrategy.cacheChangingModulesFor 0, "seconds"
}The current version is 6.6, but it still looks like this.
The first thing adds new artifact/dependency type (
providedRuntime), the second one iterates over all known types and executes some code.Yes, there are two small
here, but nothing really big IMHO:- using the word
configurationas "artifact type" is quite confusing for anyone who hasn't read the documentation - the first construct is quite confusing, it would be much better to require special keyword (something like
configurations.registerNewor something
Third league at best.
- using the word
