One more: If I have multiple modules, are multithr...

# gradle

[ursus]

One more: If I have multiple modules, are multithreaded builds enabled by default? I always thought so, because the tasks interleave during build.

But now Ive tried org.gradle.parallel=true, and get 30% speedup, is this parallel a different thing?

[gildor]

No, Gradle will not run builds of multiple modules in parallel by default, you have to specify org.gradle.parallel=true explicitly

[gildor]

https://guides.gradle.org/performance/#parallel_execution

[ursus]

Thats weird, so Ive been modularized for few months for nothing? lol, However the build speed did improve even withouth the flag

[cristiangm]

not being in parallel doesn't mean it doesn't have advantages
compile avoidance ( if you don't use kotlin )
build cache
...

[ursus]

true, but why would you not want parallel builds if you already have the separation

[cristiangm]

because Gradle cannot assume your modules are independant

[cristiangm]

You should enable parallel, but they cannot do it by default

[ursus]

how would they not be independant? they are modules = independant, no?

[cristiangm]

even thought they could have made it a default on Gradle 5.0

[ursus]

huhm compile avoidance doesnt work if I use kotlin?

[cristiangm]

you can add sourceSets or resources from other modules ( which is kind of stupid )

[ursus]

oh, yea thats silly

[ursus]

btw ive also seen kotlin.incremental=true, does that do anything?

[cristiangm]

and no, compile avoidance doesn't work YET with Kotlin

[ursus]

Im always strugging with gradle flags, as to what actuallydoes something

[ursus]

compile avoidance = not building a module you didnt touch, right?

[cristiangm]

I would say kotlin.incremental is true be default, but I don't remember from which version

[cristiangm]

compile avoidance = not compiling a module, even if a module it depends changed

[cristiangm]

it needs to understand if the change would affect you or not

[cristiangm]

( so, for example, don't compile if only an implementation has changed, but compile if the interface has changed )

[ursus]

okay so now in kotlin if I change something in base module, every other module that includes base will be recompiled?

[cristiangm]

yes

[ursus]

but, if I change feature1, then feature 2 (they are totally unrelated) doesnt get recompiled, right?

[cristiangm]

in java if the change you made on base is only an implementation detail no other module would recompile

[cristiangm]

exactly, only if it depends on the other module

[ursus]

okay so basically my implementation includes do nothing for now?

[cristiangm]

¿?

[ursus]

to get compilation avoidance I thought implementation including of modules is necessary

[cristiangm]

implementation does not propagate the dependency, so it helps too

[ursus]

what about that caching please?

[gildor]

Implementation/api != compile avoidance

[gildor]

This is one more different thing. But it also helps avoid module recompilation, but only for transitive relationships between modules

[ghedeon]

any good articles on this subject? Given: a few base modules plus feature modules on the top, all kotlin. How to speed this shit up? (I've checked the corresponding section on developer.android)

[gildor]

not sure about feature/base module, because it’s one more level of dependencies on top usual Gradle modules.
In general to speedup you should have more independent modules (maybe even not related on feature/base, just module with minimum dependencies, to make it recompilation recompile only modules that depend on it)
But it’s pretty wide topic, I would recommend first check you build scan to understand what is slow.
Also as starting point check this webinar from Gradle team
https://gradle.com/blog/improving-android-and-java-build-performance/

[ursus]

@gildor what do you mean another level of modules, its the usual diamon :base -> :feature(s) -> :app

[gildor]

I mean there are usual Gradle modules (projects) but when someone talks about base/feature modules in domain of Android it probably about instant app/app bundle dynamic modules which is additional feature where module dependencies are inverted (feature has base module in dependencies and base has list of dynamic features, and base module is your application for app bundle)
And I just don't know how this works in terms of Gradle compilation

[ursus]

oh, well I see people use base/core + features terminology as well in regular multimodule

[gildor]

Yes, but it’s very confusing to use base/feature for usual gradle modules, because base and feature is even Gradle plugin name for app bundle/instan app modiles, that my point. Core is fine, at least it’s clear that core is root of other module and doesn’t have dependencies to other core modules