Finally, it should be possible to set the default ...

# amper

[Waldemar Kornewald]

Finally, it should be possible to set the default list of lib platforms in the root build script instead of having to repeat that list in every module. Like suggested in the announcement thread, the root build script should be the preferred place for many configuration options. Per-module configs should ideally be the exception.

[Anton Prokhorov]

Do templates solve this issue?

[Waldemar Kornewald]

Templates require explicit mentioning in every module. This means every developer has to know about that convention and copy-paste the same apply section everywhere. They also have to know which of the templates is the right one.

Usually with Gradle you'd instead use the subprojects block in the root build script to configure all modules and define a convention like project.name.startswith("app-") or match on the path to apply some config to all modules within a subfolder (when you have two or more levels). This is a convention that everyone can see and follow at first glance (it's self-documenting) and it requires no copy-paste with 50 modules. That's similar to src@jvm which is also self-documenting because it's based on file/directory naming.

Templates may have their uses, but we have quite complicated and large projects with many different teams and the convention based solution works really well and helps giving you a better overview because you open just one file and see all the modules e.g. that export an XCFramework or have something else in common. This overview is missing with the templates solution. Also creating templates has its own friction. Most developers just won't do it. They'll be used to editing individual module files and start copy-paste solutions. Forcing people to apply rules from the root makes them think in better generalizations because the friction is minimal and the better overview helps with generalizing.

[Waldemar Kornewald]

As a crazy thought experiment, what if we had templates in the root folder that could be applied to child module name patterns or other properties (e.g. the product or platform)?

[Waldemar Kornewald]

Basically, my suggestion is to have a declarative way to match modules and apply rules to them.

[Anton Prokhorov]

Fair enough, good point, thanks, we will consider this feedback during our future experiments