Kotlin multiplatform projects use compilations for producing artifacts. Each target can have one or more compilations, for example, for production and test purposes.
For each target, default compilations include:
testcompilations for JVM, JS, and Native targets.
If you need to compile something other than production code and unit tests, for example, integration or performance tests, you can create a custom compilation.
You can configure how artifacts are produced in:
All compilations in your project at once.
Compilations for one target since one target can have multiple compilations.
Configure all compilations
Configure compilations for one target
Configure one compilation
Create a custom compilation
If you need to compile something other than production code and unit tests, for example, integration or performance tests, create a custom compilation.
For example, to create a custom compilation for integration tests of the
jvm() target, add a new item to the
You also need to create a custom compilation in other cases, for example, if you want to combine compilations for different JVM versions in your final artifact, or you have already set up source sets in Gradle and want to migrate to a multiplatform project.
Use Java sources in JVM compilations
When creating a project with the Project Wizard, Java sources are included in the compilations of the JVM target.
In the build script, the following section applies the Gradle
java plugin and configures the target to cooperate with it:
The Java source files are placed in the child directories of the Kotlin source roots. For example, the paths are:
The common source sets cannot include Java sources.
Due to current limitations, the Kotlin plugin replaces some tasks configured by the Java plugin:
The target's JAR task instead of
The target's test task instead of
The resources are processed by the equivalent tasks of the compilations instead of
The publication of this target is handled by the Kotlin plugin and doesn't require steps that are specific for the Java plugin.
Configure interop with native languages
Kotlin provides interoperability with native languages and DSL to configure this for a specific compilation.
All platforms, except for WebAssembly
Apple platforms (macOS, iOS, watchOS, tvOS)
Swift via Objective-C
Apple platforms (macOS, iOS, watchOS, tvOS)
Kotlin can use only Swift declarations marked with the
A compilation can interact with several native libraries. Configure interoperability in the
cinterops block of the compilation with available parameters.
Compilation for Android
The compilations created for an Android target by default are tied to Android build variants: for each build variant, a Kotlin compilation is created under the same name.
Then, for each Android source set compiled for each of the variants, a Kotlin source set is created under that source set name prepended by the target name, like the Kotlin source set
androidDebug for an Android source set
debug and the Kotlin target named
android. These Kotlin source sets are added to the variants’ compilations accordingly.
The default source set
commonMain is added to each production (application or library) variant's compilation. The
commonTest source set is similarly added to the compilations of unit test and instrumented test variants.
Annotation processing with
kapt is also supported, but due to current limitations it requires that the Android target is created before the
kapt dependencies are configured, which needs to be done in a top-level
dependencies block rather than within Kotlin source set dependencies.
Compilation of the source set hierarchy
Kotlin can build a source set hierarchy with the
If the source set
jvmMain depends on a source set
jvmMainis compiled for a certain target,
commonMaintakes part in that compilation as well and is also compiled into the same target binary form, such as JVM class files.
jvmMain'see' the declarations of
commonMain, including internal declarations, and also see the dependencies of
commonMain, even those specified as
jvmMaincan contain platform-specific implementations for the expected declarations of
The resources of
commonMainare always processed and copied along with the resources of
The language settings of
commonMainshould be consistent.
Language settings are checked for consistency in the following ways:
jvmMainshould set a
languageVersionthat is greater than or equal to that of
jvmMainshould enable all unstable language features that
commonMainenables (there's no such requirement for bugfix features).
jvmMainshould use all experimental annotations that
apiVersion, bugfix language features, and
progressiveModecan be set arbitrarily.