KSP с Kotlin Multiplatform

Для быстрого начала, см. пример проекта Kotlin Multiplatform, определяющий процессор KSP.

Начиная с KSP 1.0.1, применение KSP в многоплатформенном проекте аналогично применению в проекте JVM. Основное отличие заключается в том, что вместо записи конфигурации ksp(...) в зависимостях используется add(ksp<Target>) или add(ksp<SourceSet>), чтобы указать, какие целевые сборки требуют обработки символов перед компиляцией.

plugins {
    kotlin("multiplatform")
    id("com.google.devtools.ksp")
}

kotlin {
    jvm {
        withJava()
    }
    linuxX64() {
        binaries {
            executable()
        }
    }
    sourceSets {
        val commonMain by getting
        val linuxX64Main by getting
        val linuxX64Test by getting
    }
}

dependencies {
    add("kspMetadata", project(":test-processor"))
    add("kspJvm", project(":test-processor"))
    add("kspJvmTest", project(":test-processor")) // Not doing anything because there's no test source set for JVM
    // There is no processing for the Linux x64 main source set, because kspLinuxX64 isn't specified
    add("kspLinuxX64Test", project(":test-processor"))
}

Компиляция и обработка

В многоплатформенном проекте компиляция Kotlin может происходить несколько раз (main, test, или другие варианты сборки) для каждой платформы. То же касается обработки символов. Задача обработки символов создаётся всякий раз, когда есть задача компиляции Kotlin и указана соответствующая конфигурация ksp<Target> или ksp<SourceSet>.

Например, в приведённом выше build.gradle.kts, есть 4 компиляции: common/metadata, JVM main, Linux x64 main, Linux x64 test, и 3 задачи обработки символов: common/metadata, JVM main, Linux x64 test.

Избегайте конфигурации ksp(...) в KSP 1.0.1+

Перед KSP 1.0.1 доступна только одна объединённая конфигурация ksp(...). Поэтому процессоры либо применяются ко всем целевым сборкам, либо вообще ни к одной. Обратите внимание, что конфигурация ksp(...) применяется не только к основной сборке исходного кода, но и к тестовой сборке, если она существует, даже в традиционных, не многоплатформенных проектах. Это приводило к ненужным затратам времени на сборку.

Начиная с KSP 1.0.1, предоставляются конфигурации для каждой целевой сборки, как показано в приведённом выше примере. В будущем:

Для многоплатформенных проектов конфигурация ksp(...) будет устаревшей и удалена.
Для проектов с одной платформой конфигурация ksp(...) будет применяться только к основной, по умолчанию, компиляции. Для других целевых сборок, таких как test, потребуется указать kspTest(...) для применения процессоров.

Начиная с KSP 1.0.1, есть флаг предварительного доступа -DallowAllTargetConfiguration=false для переключения на более эффективное поведение. Если текущее поведение вызывает проблемы с производительностью, попробуйте его. Значение флага по умолчанию будет изменено с true на false в KSP 2.0.

Последнее изменение: 07 апреля 2022

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