Это не значит, что make обязано так топорно делать.
Это пример того, что система сборки по-хорошему, должна неплохо так понимать суть.

Разумеется, и для make можно сделать инструмент, который бы пробежался по core.jar, взял из него public api, и уже использовал его для сборки app.
Но тогда и make скрипт придётся хитроумно настраивать. В каждом месте вставлять эту работу с public api что-ли?

ну в make можно только описать структуру, а уже спец тул будет анализировать и принимать данные решения. Но в реальности это сложно, можно смотреть на сборку с/с++ и понимать как это больно

возможно мы про разные make говорим, но в классическом make правила описываются набором файлов и командой «что с ними делать»

да я не про классический, а некий абстрактный конь.

Тогда рекомендую (пере)смотреть https://www.youtube.com/watch?v=BQVT6wiwCxM

спасибо гляну, никогда сильно сборкой не интересовался (в плне тонкостей и кишок)

Ты опять за своё, только теперь в чате гредла?

поставил лайк!

Современная сборка это не только запуск компилятора, сложные проекты имеют сложную сборку. Для этого нужен инструмент, который бы позволял делать эти сложные вещи и организовывать их просто. Ребята из грейдла молодцы, не стоят на месте, постоянно развивают продукт, делают больше готовых решений для сложных вещей и больше инструментов для организации сложных бидлов, это очень здорово. А ворчать, что это слишком сложно может только человек, который вообще не понимает, что там происходит и не хочет понимать. С таким подходом сейчас далеко не уйдешь, сейчас современные подходы разработки предполагают, что каждый разраб немного девопс, те кто этого не понимает может скоро оказаться ща бортом

Уточню: не «каждый разраб немного девопс», а сегодня акцент в ЖЦ проекта сильно смещается от роли разраба в сторону ролей девопса и др. (бизнес-аналитиков и архитекторов).

Это я так смягчил. В серверлесе например, ты должен быть девопсом, иначе никак

Пусть там требования к девопсу немного ниже, но без этого просто ничего не пойдет

Я исхожу из того, что роль — это абстракция. В одной роли может выступать несколько человек. И наоборот: один человек может сочетать в себе несколько ролей.

Слушайте. Немного не тема чата про Gradle, но всё-таки devops это методология разработки, а не роль.
Я всё понимаю, что вакансию пишут в духе «нужен devops инженер», но считать, что «девопсы это переименованные админы» как-то нехорошо.

Я не считаю, что каждый должен досконально понимать Gradle, но, блин, на поверхностном уровне это и полезно и несложно.

Подключил к себе пару модулей из чужого проекта. Там имеется билдскрипт:

…
apply from: '../gradle/versions.gradle'
…
android {
    compileSdkVersion compileSdk
…

versions.gradle:

ext {
    …
    compileSdk = 29
…

тем не менее: Parameter specified as non-null is null: method com.android.build.gradle.BaseExtension.compileSdkVersion, parameter version

чё не так?

тоже с этим сталкивался, написано как-то так, но импорта(и файла отдельного) нет, в рутовом проекте лежит версия в ext {}

Resolving dependency configuration 'testImplementation' is not allowed as it is defined as 'canBeResolved=false'.
 Instead, a resolvable ('canBeResolved=true') dependency configuration that extends 'testImplementation' should be resolved.

Не могу нагуглить чего-то внятного =\

пробовал project и rootProject, не помогло)

ля, или помогло, ничего не понимаю

я вот тоже тогда не особо разобрался, возможно помогло что оно прям в ext еще так называется - compileSdkVersion , из ошибки мне не очень было понятно чо он от меня хочет и с каких пор, поэтому из мануала андроедного копировал