We need a build system for Kotlin. We have reached...

# multiplatform

[Abdhilahi Wabwire]

We need a build system for Kotlin. We have reached our limit with Gradle. We switched to Bazel but this is temporary. We are looking at going back to Maven. Gradle is now costing our company massive sums of money.

[Christian Oleson]

What costs so much with Gradle?

[Abdhilahi Wabwire]

Engineering time + market saturation = Cost

[Raimund Klein]

Are you saying that Maven is easier to deal with than Gradle?

[Raimund Klein]

I’m finding quite the opposite to be true.

[Abdhilahi Wabwire]

@Raimund Klein I'm not here to argue. We need a build system for Kotlin, until we have that, the problem will continue.

[brandonmcansh]

Make one

[Abdhilahi Wabwire]

@brandonmcansh You should ask yourself if that's what you want developers to start doing. If we do, you may be surprised by the outcome

[jw]

Use Make

[Abdhilahi Wabwire]

Thank you @jw aren't you the famous RxJava guy?

[eygraber]

There is a build system for Kotlin. It's called Gradle, and it works great, certainly better than most other build tools I've worked with in the past. Sure there's a steep learning curve, but once you stop fighting what you think it should be, and dedicate time to learning what it is, the process gets much smoother.

Dedicating time to learning the proper way to use Gradle is going to be much more cost effective than coming up with your own build system (which probably won't work as well as Gradle).

[jw]

There's also Amper, but Gradle seems like the better choice

[eygraber]

I have a sneaking suspicion that Amper is going to be sunset in the near future with the findings from it getting rolled into Gradle/KGP

[jw]

It's a weird thing to build

[Abdhilahi Wabwire]

Thank you @eygraber we are doing everything we can to try to use Gradle properly. Reading all of the documentation. We will keep trying but for now we also have engineers working on using Bazel and Maven. && as for @brandonmcansh we may make a build system just to spite him, since he thinks it is impossible for developers to do.

[Abdhilahi Wabwire]

Thank you @jw we will try Amper

[ian.shaun.thomas]

You might win some support if you explained the insurmountable issues or at least made it clear what kind of response you're looking for.

[Abdhilahi Wabwire]

@ian.shaun.thomas @Justin Salér @jw @brandonmcansh @eygraber Migrating a Jetpack Compose product to a Compose Multiplatform product has caused the destruction of our entire build flow. We are highly adept at using Gradle and some of our engineers have been using it for over 2 years. Yet this migration has forced us to reconsider using Gradle at all. Bugs, project restructuring, sourceSet management is the worst of these. Adding dependencies to Kotlin sourceSets like commonMain instead of declaring them in the standard dependency structs causes massive bugs everywhere. Even when you declare them in the standard dependency structs, restructuring doesn't fix the problem. Resource sourceSets are broken for Multiplatform builds. It has now been over a week and we still have no fix. Builds have just stopped at our company entirely while we work on this issue. We have had to watch Gradle fail in ever increasingly hilarious ways. The response I'm looking for is a "Yes, we will make a build system for Kotlin or fix Gradle or add better Maven support or Bazel support because we created the language and it is our responsibility" - Instead of defending Gradle like we are all married to it.

[Christian Oleson]

Can we avoid @‘ing people? I duched out of this conversation after i got the info i was curious about.

[chr]

Migrating a project from one framework to another is never easy but I think it's a bit dishonest to blame the build system for that. Gradle does have its warts (as all build systems do, including the one you might build "out of spite") but many companies have used it at immensely large scales to great benefit, especially using the plugin system that lets you incorporate the work of other developers that have solved hard problems so the rest of us don't have to.

There is a good amount of support here and I think if you had specific, constructive questions about the issues you're running into, there's a large forum of support forums, GitHub Issues, and public Slack instances like this where you can find advice from other developers or even Gradle/JB developers themselves. If you run into arcane issues with some lesser-known (or completely custom) build tooling, you may find it much harder to get answers.

[Abdhilahi Wabwire]

Thank you Christian De Angelis. We are reverting the product back to Jetpack Compose until we can figure out how to solve our Compose Multiplatform issues. Blaming the build system is valid because these are build issues and not code issues, for a build system that we have been using for years so we have seen all the craziness it allows. Gradle deprecates our builds with every upgrade. We have looked absolutely everywhere for answers and will keep looking. After this experience though, Maven's pom.xml looks really modern. Starlark is starting to look physically attractive.

[Pamela Hill]

Hi folks, just a reminder of the code of conduct for Kotlinlang Slack. Let's be kind and try to solve problems and be constructive, not argumentative. Any questions on this to moderators and admins. cc @gildor Thanks and have a lovely day!

[Pamela Hill]

I understand frustration being experienced, but let's try to keep things constructive.

[hfhbd]

Build tools are complex by design, especially ones with extensive plugin support. On top, the Kotlin multiplatform plugin is complex too. Feel free to use any another tool but I don’t think there is a generic better option.
Or ask for help with Gradle.

[Javier]

@eygraber Gradle only needs to cleanup eagerly configurations and some weird callbacks like afterEvaluate.

The main problem a new developer will found with Gradle without spending time in learning the tool (all people do that) is the developer will use 99% times the non lazy APIs because they are the easiest ones to be found by intuition.

I wouldn’t release Gradle 9.0 without marking a lot of elements as deprecated to fire them in Gradle 10.

IMO it is the time to fire wrong things even if that means slowing the progress in features, and I would love to see project isolation working as soon as possible but… who cares this feature becomes stable if all third party plugins will not support it? I still have problems even enabling configuration cache due two incompatible plugins that are build in the wrong but intuitive way.

[Abdhilahi Wabwire]

Solved the problem. Had to search through every single Multiplatform sample available. This was not easy. We still want a build system for Kotlin. We still feel that XML/YAML/TOML would solve a lot of problems. We still feel that declarative is the best way to go. The problem was with sourceSets, there needs to be an easier way of pointing to sourceSets that are not in standard locations. Gradle gets confused when you don't use the precise syntax and when you do it still looks in the wrong place. We had to write custom logic to fix the problem.

[Javier]

What was the problem

[Abdhilahi Wabwire]

Here is how we fixed it:

sourceSets {
create("android") {
manifest.srcFile("src/android/AndroidManifest.xml")
res.srcDirs("src/android/res")
}

sourceSets {
create("lib") {
java.srcDir("src/lib/kotlin")
resources.srcDir("src/lib/resources")
}

sourceSets {
getByName("android") {
manifest.srcFile("src/android/AndroidManifest.xml")
res.srcDirs("src/android/res")
}
}

sourceSets {
getByName("lib") {
java.srcDir("src/lib/kotlin")
resources.srcDir("src/lib/resources")
}
}

dependencies {
sourceSets.named("lib") {

}
}

Here is where it is missing in the documentation:
• https://developer.android.com/build/build-variants#sourcesets
• https://kotlinlang.org/docs/multiplatform-get-started.html
• https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-samples.html
Because this solution, along with some extra logic, was not in the documentation (including the Gradle documentation), many other solutions were tried because we did not know what the exact problem was. That took days worth of time.

[Javier]

What did you fix

[Abdhilahi Wabwire]

We have a specific project structure that we implemented. Gradle was unable to understand the project structure with Compose Multiplatform. Gradle could not figure out what directory was where or how to share logic between directories. We glued our logic together and created new sourceSets. But in order to do that, we first tried other fixes that didn't work because we had to narrow down the issue. Restructuring the project several times. All this to migrate from Jetpack Compose to Compose Multiplatform and we achieved it with great success, pain and an undocumented solution sitting in someone's GitHub repository:

https://github.com/Baeldung/kotlin-tutorials

[ian.shaun.thomas]

Based on the answer I think a lot of your pain might be rooted in avoiding modules. Why not put that library code into its own module in the project?

[Abdhilahi Wabwire]

I'm not sure if that will increase or decrease the complexity of our already complex build but I will look into it

[Javier]

We have a specific project structure that we implemented

So you are lucky to be able to do that thanks to the flexibility Gradle provides and you would lose with a strict build system based on Yaml. I don't understand your initial point.

[Abdhilahi Wabwire]

I apologize if I seem ungrateful in any way. This was really difficult for everyone on my team and they are good engineers. I'm not that bad myself, but they are better and this was still hard. I have used C#, Dart, Go and Swift extensively. With interoperated builds. I thought C-GO was hard. This was hard.

[brandonmcansh]

lol I was saying make one because you’ve complained two times in two days about gradle.

IMHO the gradle system works for its use case

[McEna]

@Abdhilahi Wabwire Instead of having a very complex repo structure, why not just move your multiplatform code to another repo? As I understand, the artifacts produced by KMM are just regular, platform dependencies. So your original project structure could just import those. You would only need an extra repo for the new platform targets, but your current android structure would not be affected. Also, while I love Maven, Gradle's ability to run groovy/kotlin/JVM code means you can do pretty much anything.

[ian.shaun.thomas]

Really no reason to add another repo. You can get great build times using a monolithic approach. Even more when you realize how powerful composite builds can be.

[McEna]

The OP mentioned having a customized project layout. Introducing a new stack will always break a bunch of things in those cases.