Oliver.O
06/03/2022, 7:34 PMcommonTest
),
• auto-registers source directories, making the IDE happy.
The code works in build.gradle.kts
, now I'm trying to apply the fixes to the KSP Gradle plugin. If that's OK, I'd come up with a PR (which would initially provide the fixes for multiplatform only, as I do not currently use Android builds).
There is one issue to be resolved: Ideally, I'd like to use a single point of configuration like so (which works nicely with build script code):
kotlin {
// ...
sourceSets {
val commonMain by getting {
withKsp(project(":test-processor"))
}
}
To achieve that, I need to find a way for Gradle to load this extension function from the plugin into the buildscript classpath:
fun KotlinSourceSet.withKsp(dependencyNotation: Any)
Note: KotlinSourceSet
is not even extension-aware.
Is this at all possible? Any ideas?Fudge
06/04/2022, 8:44 AMksp
configuration right?
You should be able to iterate through all dependencies with the ksp configuration in afterEvaluate{}Oliver.O
06/04/2022, 10:36 AMadd
invocation inside a dependencies
block. You have to use a ksp configuration name, which is a modified form of the sourceSet name and not fully documented. For users, it would be easier to just use a sourceSet name directly, ideally in kotlin.sourceSets
, avoiding repetition. I already got everything working with the Gradle plugin. This is just a matter of offering the easiest to use DSL for configuration to the plugin’s users.Fudge
06/05/2022, 8:49 AMksp
and giving it a method e.g. processor
and then it's used like:
ksp.processor(project(...))
Oliver.O
06/05/2022, 1:06 PMksp
extension already exists and configures KSP globally. So ksp.processor(...)
would configure a processor globally. Now I'd like to configure a source set-specific processor. Currently, I have implemented it this way:
sourceSets {
val commonMain by getting {
ksp {
processor(project(":test-processor"))
}
}
}
Ideally, KotlinSourceSet
would be extension-aware, so we could create ksp
extensions for source sets. Unfortunately, this is not the case. So I defined the above processor
in the KspExtension
class as fun KotlinSourceSet.processor(dependencyNotation: Any)
. That way, even though we are using the global ksp
extension, processor
can pick up the source set from the context via its receiver.
While this is one level of indirection more than I had hoped for originally, it opens up a path for source set-specific options, e.g.
sourceSets {
val commonMain by getting {
ksp {
processor(project(":test-processor"))
arg("option1", "value1")
allWarningsAsErrors = true
}
}
}
natario1
06/06/2022, 1:40 AMKotlinSourceSet
extension aware looks like a legitimate feature requestFudge
06/06/2022, 7:59 PMOliver.O
06/06/2022, 8:43 PMksp { processor(...) }
is mandatory within a source set block. processor
needs to have two receivers in scope: KspExtention
via ksp {...}
and KotlinSourceSet
via getting {...}
. See the above definition of the processor
extension function.Fudge
06/09/2022, 6:27 PMKspExtension
receiver is given explicitly when you do ksp.processor()
Oliver.O
06/09/2022, 6:32 PMKotlinSourceSet
) in scope so that we have both?russhwolf
06/09/2022, 6:33 PMnatario1
06/10/2022, 3:10 PMKotlinSourceSet
to be extension aware.Oliver.O
06/14/2022, 7:37 PMAlex Vanyo
06/14/2022, 8:30 PMA
to both commonMain
and jvmMain
. Assuming A
does something simple, like generating code for a class with an annotation, right now (at least with my setup), everything from commonMain
will be generated twice, which causes duplicate class issues.jvmMain
only look at code in jvmMain
?Oliver.O
06/14/2022, 8:48 PMsourceSets {
val commonMain by getting {
ksp {
processor(project(":test-processor"))
arg("output", "commonMain")
}
}
val jvmMain by getting {
ksp {
processor(project(":test-processor"))
arg("output", "jvmMain")
}
}
}
In the future, KSP hopefully could provide more information, e.g. each processed file's (input) source set. Combine this with the above output
source set information, and you could filter out unwanted files.
So TL;DR: The above is the first step towards a more convenient solution. Until then, you could use the workarounds mentioned in https://github.com/google/ksp/issues/965.Alex Vanyo
06/14/2022, 8:54 PMevant
06/14/2022, 9:01 PMIn the future, KSP hopefully could provide more information, e.g. each
processed file's (input) source set. Combine this with the aboveTo me it makes sense that this would be the default at least for saysource set information, and you could filter out unwanted files.output
getSymbolsWithAnnotation
unless there's usecases I'm missing?Alex Vanyo
06/14/2022, 9:10 PM@MyAnnotation
expect fun something()
Not sure if that’s an actual use case, just speculating.evant
06/14/2022, 9:12 PMMatthias Geisler
06/14/2022, 9:32 PMdependencies { add("ksp...") }
when the KMP Plugin is applied? Currently it throws an error when you for example try to register kspClientTest
- is that preserved?Oliver.O
06/18/2022, 12:45 PMdependencies {…}
should be unchanged.Matthias Geisler
08/22/2022, 5:56 AM