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("kspCommonMainMetadata", 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.

Последнее изменение: 21 октября 2022

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