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.

Последнее изменение: 08 июня 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