Multiplatform and non-Gradle projects

1

Current multiplatform support seems very Gradle-centric. Are non-Gradle projects supported? Someday? Ant perhaps?

1 Like
2

I believe that while Ant and Maven were specifically designed to be used for Java projects, Gradle was designed to be adaptable for building any language, so probably not.

1 Like
3

If you can’t live without ant, you can use it from inside gradle.
Though I do not really know, why you would do that. I was a great fan of maven in my own time, but now gradle beats it in any possible sense.

4

There’s some limited support of multiplatform projects in maven, though it’s not being developed actively ATM.
For example kotlinx.html is a maven multiplatform library.

5

My team has spent a significant amount of time moving over to Gradle for our projects.
Previously we had a proprietary build system written in Kotlin that invoked the CLI compilers in the Kotlin plugin.

I have to say, I liked the old way a lot better. It was faster, more stable, easier to write custom tasks, safer, and above all, more cost-effective to maintain.
I understand why the Kotlin team decided to go with Gradle as their standard way of doing things, I’m not here to rant about Gradle (although tempted), I’m here to ask some questions about multiplatform Kotlin sans Gradle.

  • Is Gradle the only way to get the expects/actual feature for multi-platform modules?
  • In Kotlin modules, the .iml supports JAVA_MODULE and JS_MODULE. Is there any planning (even unofficial) support for MULTIPLATFORM_MODULE? With the proprietary system I just treated common modules as JVM modules then compiled them for the different backends. This worked fine except that it was easy to accidentally import things like java.utils.*.
  • In the Kotlin plugin I see compilers for JS, JVM, and Metadata. How does Gradle build for Native? I’m curious what the path would look like for building for WebASM without Gradle.

Best,
Nick