Настройка компиляций

В проектах Kotlin Multiplatform компиляции используются для создания артефактов. Для каждой целевой платформы может быть одна или несколько компиляций, например, для production-кода и тестов.

Для каждой целевой платформы по умолчанию создаются следующие компиляции:

Компиляции main и test для целевых платформ JVM, JS и Native.
Компиляция для каждого варианта сборки Android для целевых платформ Android.

Если вам нужно компилировать не только production-код и модульные тесты, например интеграционные тесты или тесты производительности, вы можете создать пользовательскую компиляцию.

Вы можете настроить способ создания артефактов для:

Всех компиляций в проекте одновременно.
Компиляций одной целевой платформы, поскольку для одной целевой платформы может быть несколько компиляций.
Отдельной компиляции.

См. список параметров компиляции и параметры компилятора, доступные для всех целевых платформ или для отдельных из них.

Настройка всех компиляций

В этом примере настраивается параметр компилятора, общий для всех целевых платформ:

kotlin {
    compilerOptions {
        allWarningsAsErrors.set(true)
    }
}

kotlin {
    compilerOptions {
        allWarningsAsErrors = true
    }
}

Настройка компиляций одной целевой платформы

kotlin {
    jvm {
        compilerOptions {
            jvmTarget.set(JvmTarget.JVM_1_8)
        }
    }
}

kotlin {
    jvm {
        compilerOptions {
            jvmTarget = JvmTarget.JVM_1_8
        }
    }
}

Настройка одной компиляции

kotlin {
    jvm {
        val main by compilations.getting {
            compileTaskProvider.configure {
                compilerOptions {
                    jvmTarget.set(JvmTarget.JVM_1_8)
                }
            }
        }
    }
}

kotlin {
    jvm {
        compilations.main {
            compileTaskProvider.configure {
                compilerOptions {
                    jvmTarget = JvmTarget.JVM_1_8
                }
            }
        }
    }
}

Создание пользовательской компиляции

Если вам нужно компилировать не только production-код и модульные тесты, например интеграционные тесты или тесты производительности, создайте пользовательскую компиляцию.

Для пользовательских компиляций все зависимости необходимо настроить вручную. Набор исходного кода пользовательской компиляции по умолчанию не зависит от наборов исходного кода commonMain и commonTest.

Например, чтобы создать пользовательскую компиляцию для интеграционных тестов целевой платформы jvm, настройте отношение associateWith между компиляциями integrationTest и main:

kotlin {
    jvm {
        compilations {
            val main by getting
            val integrationTest by creating {
                // Import main and its classpath as dependencies and establish internal visibility
                associateWith(main)
                defaultSourceSet {
                    dependencies {
                        implementation(kotlin("test-junit"))
                        /* ... */
                    }
                }
            }

            // Create a test task to run the tests produced by this compilation:
            testRuns.create("integration") {
                // Configure the test task
                setExecutionSourceFrom(integrationTest)
            }
        }
    }
}

kotlin {
    jvm {
        compilations.create('integrationTest') {
            def main = compilations.main
            // Import main and its classpath as dependencies and establish internal visibility
            associateWith(main)
            defaultSourceSet {
                dependencies {
                    implementation kotlin('test-junit')
                    /* ... */
                }
            }
        }

        // Create a test task to run the tests produced by this compilation
        testRuns.create('integration') {
            // Configure the test task
            setExecutionSourceFrom(compilations.integrationTest)
        }
    }
}

Связывая компиляции, вы добавляете выходные данные основной компиляции в качестве зависимости и настраиваете видимость internal между компиляциями.

Пользовательские компиляции нужны и в других случаях. Например, если вы хотите объединить компиляции для разных версий JVM в итоговом артефакте или уже настроили наборы исходного кода в Gradle и хотите перейти на многоплатформенный проект.

Компиляция для JVM

Когда вы объявляете целевую платформу jvm в многоплатформенном проекте, плагин Kotlin Multiplatform Gradle автоматически создает наборы исходного кода Java и включает их в компиляции целевой платформы JVM.

Общие наборы исходного кода не могут содержать ресурсы Java, поэтому их следует размещать в соответствующих дочерних каталогах многоплатформенного проекта. Например:

В настоящее время плагин Kotlin Multiplatform Gradle заменяет некоторые задачи, настроенные плагином Java:

Задача JAR: вместо стандартной задачи jar используется задача, предназначенная для конкретной целевой платформы и названная по имени артефакта, например jvmJar для объявления целевой платформы jvm() и desktopJar для jvm("desktop").
Задача тестирования: вместо стандартной задачи test используется задача, предназначенная для конкретной целевой платформы и названная по имени артефакта, например jvmTest.
Обработка ресурсов: вместо задач *ProcessResources ресурсы обрабатываются соответствующими задачами компиляции.

Эти задачи создаются автоматически при объявлении целевой платформы. Однако при необходимости вы можете вручную определить задачу JAR и настроить ее:

// Shared module's `build.gradle.kts` file
plugins {
    kotlin("multiplatform") version "2.4.20"
}

kotlin {
    // Specify the JVM target
    jvm {
        // Add the task for JAR generation
        tasks.named<Jar>(artifactsTaskName).configure {
            // Configure the task
        }
    }

    sourceSets {
        jvmMain {
            dependencies {
                // Add JVM-specific dependencies
            }
        }
    }
}

// Shared module's `build.gradle` file
plugins {
    id 'org.jetbrains.kotlin.multiplatform' version '2.4.20'
}

kotlin {
    // Specify the JVM target
    jvm {
        // Add the task for JAR generation
        tasks.named<Jar>(artifactsTaskName).configure {
            // Configure the task
        }
    }

    sourceSets {
        jvmMain {
            dependencies {
                // Add JVM-specific dependencies
            }
        }
    }
}

Эта целевая платформа публикуется плагином Kotlin Multiplatform Gradle и не требует выполнения шагов, специфичных для плагина Java.

Настройка взаимодействия с нативными языками

Kotlin поддерживает взаимодействие с нативными языками и предоставляет DSL для его настройки в конкретной компиляции.

Нативный язык	Поддерживаемые платформы	Комментарии
C	Все платформы
Objective-C	Платформы Apple (macOS, iOS, watchOS, tvOS)
Swift через Objective-C	Платформы Apple (macOS, iOS, watchOS, tvOS)	Kotlin может использовать только объявления Swift, помеченные атрибутом `@objc`.

Компиляция может взаимодействовать с несколькими нативными библиотеками. Настройте взаимодействие с помощью доступных свойств в файле определения или в блоке cinterops файла сборки:

kotlin {
    linuxX64 { // Replace with a target you need.
        compilations.getByName("main") {
            val myInterop by cinterops.creating {
                // Def-file describing the native API.
                // The default path is src/nativeInterop/cinterop/<interop-name>.def
                definitionFile.set(project.file("def-file.def"))
                
                // Package to place the Kotlin API generated.
                packageName("org.sample")
                
                // Options to be passed to compiler by cinterop tool.
                compilerOpts("-Ipath/to/headers")
              
                // Directories to look for headers.
                includeDirs.apply {
                    // Directories for header search (an equivalent of the -I<path> compiler option).
                    allHeaders("path1", "path2")
                    
                    // Additional directories to search headers listed in the 'headerFilter' def-file option.
                    // -headerFilterAdditionalSearchPrefix command line option equivalent.
                    headerFilterOnly("path1", "path2")
                }
                // A shortcut for includeDirs.allHeaders.
                includeDirs("include/directory", "another/directory")
            }
            
            val anotherInterop by cinterops.creating { /* ... */ }
        }
    }
}

kotlin {
    linuxX64 { // Replace with a target you need.
        compilations.main {
            cinterops {
                myInterop {
                    // Def-file describing the native API.
                    // The default path is src/nativeInterop/cinterop/<interop-name>.def
                    definitionFile = project.file("def-file.def")
                    
                    // Package to place the Kotlin API generated.
                    packageName 'org.sample'
                    
                    // Options to be passed to compiler by cinterop tool.
                    compilerOpts '-Ipath/to/headers'
                    
                    // Directories for header search (an equivalent of the -I<path> compiler option).
                    includeDirs.allHeaders("path1", "path2")
                    
                    // Additional directories to search headers listed in the 'headerFilter' def-file option.
                    // -headerFilterAdditionalSearchPrefix command line option equivalent.
                    includeDirs.headerFilterOnly("path1", "path2")
                    
                    // A shortcut for includeDirs.allHeaders.
                    includeDirs("include/directory", "another/directory")
                }
                
                anotherInterop { /* ... */ }
            }
        }
    }
}

Компиляция для Android

Компиляции, создаваемые по умолчанию для целевой платформы Android, связаны с вариантами сборки Android: для каждого варианта сборки создается компиляция Kotlin с таким же именем.

Затем для каждого набора исходного кода Android, компилируемого для каждого из вариантов, создается набор исходного кода Kotlin. Его имя состоит из имени целевой платформы и имени набора исходного кода. Например, для набора исходного кода Android debug и целевой платформы Kotlin с именем android создается набор исходного кода Kotlin androidDebug. Затем эти наборы исходного кода Kotlin добавляются в компиляции соответствующих вариантов.

Набор исходного кода по умолчанию commonMain добавляется в компиляцию каждого production-варианта (приложения или библиотеки). Аналогично, набор исходного кода commonTest добавляется в компиляции вариантов модульных тестов и инструментированных тестов.

Также поддерживается обработка аннотаций с помощью kapt, но из-за текущих ограничений целевую платформу Android необходимо создать до настройки зависимостей kapt. Это нужно сделать в блоке dependencies {} верхнего уровня, а не в зависимостях наборов исходного кода Kotlin.

kotlin {
    android { /* ... */ }
}

dependencies {
    kapt("com.my.annotation:processor:1.0.0")
}

Компиляция иерархии наборов исходного кода

Kotlin может создавать иерархию наборов исходного кода с отношением dependsOn.

Если набор исходного кода jvmMain зависит от набора исходного кода commonMain, то:

При каждой компиляции jvmMain для определенной целевой платформы commonMain также участвует в этой компиляции и компилируется в тот же формат двоичного файла для целевой платформы, например в файлы классов JVM.
Исходный код jvmMain «видит» объявления commonMain, включая объявления с модификатором internal, а также зависимости commonMain, в том числе указанные как зависимости implementation.
jvmMain может содержать платформенно-зависимые реализации для ожидаемых объявлений commonMain.
Ресурсы commonMain всегда обрабатываются и копируются вместе с ресурсами jvmMain.
Настройки языка для jvmMain и commonMain должны быть согласованы.

Согласованность настроек языка проверяется следующими способами:

Для jvmMain необходимо задать languageVersion, значение которого больше или равно значению для commonMain.
В jvmMain должны быть включены все нестабильные языковые возможности, включенные в commonMain (для исправлений ошибок такого требования нет).
В jvmMain должны использоваться все экспериментальные аннотации, используемые в commonMain.
Параметры apiVersion, языковые возможности для исправления ошибок и progressiveMode можно задавать произвольно.

Настройка функции Isolated Projects в Gradle

Gradle предоставляет функцию Isolated Projects, которая повышает производительность сборки, «изолируя» проекты друг от друга. Эта функция разделяет скрипты сборки и плагины проектов, позволяя безопасно выполнять их параллельно.

Чтобы включить эту функцию, следуйте инструкциям Gradle и задайте системное свойство.

Дополнительные сведения о функции Isolated Projects см. в документации Gradle.

19 февраля 2026 г.

© 2010–2026 JetBrains s.r.o. and Kotlin Programming Language contributors
Licensed under the Apache License, Version 2.0.
https://kotlinlang.org/docs/multiplatform/multiplatform-configure-compilations.html