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.

Последнее изменение: 10 января 2023

© 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