Multiplatform Gradle DSL reference
The Kotlin Multiplatform Gradle plugin is a tool for creating Kotlin Multiplatform projects. Here we provide a reference of its contents; use it as a reminder when writing Gradle build scripts for Kotlin Multiplatform projects. Learn the concepts of Kotlin Multiplatform projects, how to create and configure them.
Id and version
The fully qualified name of the Kotlin Multiplatform Gradle plugin is org.jetbrains.kotlin.multiplatform
. If you use the Kotlin Gradle DSL, you can apply the plugin with kotlin("multiplatform")
. The plugin versions match the Kotlin release versions. The most recent version is 2.1.0.
Top-level blocks
kotlin {}
is the top-level block for multiplatform project configuration in the Gradle build script. Inside kotlin {}
, you can write the following blocks:
Block | Description |
---|---|
<targetName> | Declares a particular target of a project. The names of available targets are listed in the Targets section. |
| Lists all targets of the project. |
| Configures predefined and declares custom source sets of the project. |
| Specifies common extension-level compiler options that are used as defaults for all targets and shared source sets. |
Targets
A target is a part of the build responsible for compiling, testing, and packaging a piece of software aimed at one of the supported platforms. Kotlin provides targets for each platform, so you can instruct Kotlin to compile code for that specific target. Learn more about setting up targets.
Each target can have one or more compilations. In addition to default compilations for test and production purposes, you can create custom compilations.
The targets of a multiplatform project are described in the corresponding blocks inside kotlin {}
, for example, jvm
, androidTarget
, iosArm64
. The complete list of available targets is the following:
Target platform | Target | Comments |
---|---|---|
Kotlin/JVM |
| |
Kotlin/Wasm |
| Use it if you plan to run your projects in the JavaScript runtime. |
| Use it if you need support for the WASI system interface. | |
Kotlin/JS |
| Select the execution environment:
Learn more in Setting up a Kotlin/JS project. |
Kotlin/Native | Learn about currently supported targets for the macOS, Linux, and Windows hosts in Kotlin/Native target support. | |
Android applications and libraries |
| Manually apply an Android Gradle plugin: You can only create one Android target per Gradle subproject. |
The configuration of a target can include two parts:
Common configuration available for all targets.
Target-specific configuration.
Each target can have one or more compilations.
Common target configuration
In any target block, you can use the following declarations:
Name | Description |
---|---|
| The Kotlin platform for this target. Available values: |
| The name of the task that builds the resulting artifacts of this target. |
| Components used to set up Gradle publications. |
| Compiler options used for the target. This declaration overrides any |
JVM targets
In addition to common target configuration, jvm
targets have a specific function:
Name | Description |
---|---|
| Includes Java sources into the JVM target's compilations. |
Use this function for projects that contain both Java and Kotlin source files. Note that the default source directories for Java sources don't follow the Java plugin's defaults. Instead, they are derived from the Kotlin source sets. For example, if the JVM target has the default name jvm
, the paths are src/jvmMain/java
(for production Java sources) and src/jvmTest/java
for test Java sources. Learn more about Java sources in JVM compilations.
Web targets
The js {}
block describes the configuration of Kotlin/JS targets, and the wasmJs {}
block describes the configuration of Kotlin/Wasm targets interoperable with JavaScript. They can contain one of two blocks depending on the target execution environment:
Name | Description |
---|---|
Configuration of the browser target. | |
Configuration of the Node.js target. |
Learn more about configuring Kotlin/JS projects.
A separate wasmWasi {}
block describes the configuration of Kotlin/Wasm targets that support the WASI system interface. Here, only the nodejs
execution environment is available:
All the web targets, js
, wasmJs
, and wasmWasi
, also support the binaries.executable()
call. It explicitly instructs the Kotlin compiler to emit executable files. For more information, see Execution environments in the Kotlin/JS documentation.
Browser
browser {}
can contain the following configuration blocks:
Name | Description |
---|---|
| Configuration of test execution. |
| Configuration of project running. |
| Configuration of project bundling with Webpack. |
| Path to output files. |
Node.js
nodejs {}
can contain configurations of test and run tasks:
Name | Description |
---|---|
| Configuration of test execution. |
| Configuration of project running. |
Native targets
For native targets, the following specific blocks are available:
Name | Description |
---|---|
| Configuration of binaries to produce. |
| Configuration of interop with C libraries. |
Binaries
There are the following kinds of binaries:
Name | Description |
---|---|
| Product executable. |
| Test executable. |
| Shared library. |
| Static library. |
| Objective-C framework. |
For binary configuration, the following parameters are available:
Name | Description |
---|---|
| The compilation from which the binary is built. By default, |
| Options passed to a system linker during binary building. |
| Custom base name for the output file. The final file name will be formed by adding system-dependent prefix and postfix to this base name. |
| The entry point function for executable binaries. By default, it's |
| Access to the output file. |
| Access to the link task. |
| Access to the run task for executable binaries. For targets other than |
| For Objective-C frameworks. Includes a static library instead of a dynamic one. |
Learn more about building native binaries.
CInterops
cinterops
is a collection of descriptions for interop with native libraries. To provide an interop with a library, add an entry to cinterops
and define its parameters:
Name | Description |
---|---|
| The |
| Package prefix for the generated Kotlin API. |
| Options to pass to the compiler by the cinterop tool. |
| Directories to look for headers. |
| Header to be included in the bindings. |
| The list of headers to be included in the bindings. |
For more cinterop properties, see Definition file.
Android targets
The Kotlin Multiplatform plugin contains two specific functions for android targets. Two functions help you configure build variants:
Name | Description |
---|---|
| Specifies build variants to publish. Learn more about publishing Android libraries. |
| Publishes all build variants. |
Learn more about compilation for Android.
Source sets
The sourceSets {}
block describes source sets of the project. A source set contains Kotlin source files that participate in compilations together, along with their resources, dependencies, and language settings.
A multiplatform project contains predefined source sets for its targets; developers can also create custom source sets for their needs.
Predefined source sets
Predefined source sets are set up automatically upon creation of a multiplatform project. Available predefined source sets are the following:
Name | Description |
---|---|
| Code and resources shared between all platforms. Available in all multiplatform projects. Used in all main compilations of a project. |
| Test code and resources shared between all platforms. Available in all multiplatform projects. Used in all test compilations of a project. |
<targetName><compilationName> | Target-specific sources for a compilation. <targetName> is the name of a predefined target and <compilationName> is the name of a compilation for this target. Examples: |
With Kotlin Gradle DSL, the sections of predefined source sets should be marked by getting
.
Learn more about source sets.
Custom source sets
Custom source sets are created by the project developers manually. To create a custom source set, add a section with its name inside the sourceSets
section. If using Kotlin Gradle DSL, mark custom source sets by creating
.
Note that a newly created source set isn't connected to other ones. To use it in the project's compilations, connect it with other source sets.
Source set parameters
Configurations of source sets are stored inside the corresponding blocks of sourceSets {}
. A source set has the following parameters:
Name | Description |
---|---|
| Location of Kotlin source files inside the source set directory. |
| Location of resources inside the source set directory. |
| |
| Dependencies of the source set. |
| Language settings applied to the source set. |
Compilations
A target can have one or more compilations, for example, for production or testing. There are predefined compilations that are added automatically upon target creation. You can additionally create custom compilations.
To refer to all or some particular compilations of a target, use the compilations
object collection. From compilations
, you can refer to a compilation by its name.
Learn more about configuring compilations.
Predefined compilations
Predefined compilations are created automatically for each target of a project except for Android targets. Available predefined compilations are the following:
Name | Description |
---|---|
| Compilation for production sources. |
| Compilation for tests. |
Custom compilations
In addition to predefined compilations, you can create your own custom compilations. To create a custom compilation, add a new item into the compilations
collection. If using Kotlin Gradle DSL, mark custom compilations by creating
.
Learn more about creating a custom compilation.
Compilation parameters
A compilation has the following parameters:
Name | Description |
---|---|
| The compilation's default source set. |
| Source sets participating in the compilation. |
| Source sets participating in the compilation and their connections via |
| Compiler options applied to the compilation. For the list of available options, see Compiler options. |
| Gradle task for compiling Kotlin sources. |
| Name of |
| Name of the Gradle task for compiling all sources of a compilation. |
| The compilation output. |
| Compile-time dependency files (classpath) of the compilation. For all Kotlin/Native compilations, this automatically includes standard library and platform dependencies. |
| Runtime dependency files (classpath) of the compilation. |
Compiler options
You can configure compiler options in your projects at three different levels:
Extension level, in the
kotlin {}
block.Target level, in a target block.
Compilation unit level, usually in a specific compilation task.
Settings at a higher level work as defaults for the level below:
Compiler options set at the extension level are the default for target-level options, including shared source sets like
commonMain
,nativeMain
, andcommonTest
.Compiler options set at the target level are the default for options at the compilation unit (task) level, like
compileKotlinJvm
andcompileTestKotlinJvm
tasks.
Configurations made at a lower level override similar settings at higher levels:
Task-level compiler options override similar settings at the target or extension level.
Target-level compiler options override similar settings at the extension level.
For the list of possible compiler options, see All compiler options.
Extension level
To configure compiler options for all targets in your project, use the compilerOptions {}
block at the top level:
Target level
To configure compiler options for a specific target in your project, use the compilerOptions {}
block inside the target block:
Compilation unit level
To configure compiler options for a specific task, use the compilerOptions {}
block inside the task:
To configure compiler options for a specific compilation, use the compilerOptions {}
block within the compilation's task provider:
Dependencies
The dependencies {}
block of the source set declaration contains the dependencies of this source set.
Learn more about configuring dependencies.
There are four types of dependencies:
Name | Description |
---|---|
| Dependencies used in the API of the current module. |
| Dependencies used in the module but not exposed outside it. |
| Dependencies used only for compilation of the current module. |
| Dependencies available at runtime but not visible during compilation of any module. |
Additionally, source sets can depend on each other and form a hierarchy. In this case, the dependsOn()
relation is used.
Source set dependencies can also be declared in the top-level dependencies {}
block of the build script. In this case, their declarations follow the pattern <sourceSetName><DependencyKind>
, for example, commonMainApi
.
Language settings
The languageSettings {}
block of a source set defines certain aspects of project analysis and build. The following language settings are available:
Name | Description |
---|---|
| Provides source compatibility with the specified version of Kotlin. |
| Allows using declarations only from the specified version of Kotlin bundled libraries. |
| Enables the specified language feature. The available values correspond to the language features that are currently experimental or have been introduced as such at some point. |
| Allows using the specified opt-in annotation. |
| Enables the progressive mode. |