And one last one - with ksp being a separate task ...
# ksp
z
And one last one - with ksp being a separate task now, is there any thought to possible allowing ksp mixing into an existing/standard project that otherwise uses standard kotlin? I'd like to look at using ksp in small isolated parts of our project, but last time I tried it seemed you either have to use KSP's fork for everything in the repo. Or if that's the goal anyway, any sense of allowing for that sooner than stable to help facilitate wider adoption/testing?
t
When KSP's Gradle plugin is loaded, e.g.,
plugins { id("symbol-processing") version "1.4.10-dev-experimental-20201120" }
, a task is created for each compilation task. It is not that independent for current implementation. However, with some patches to upstream / kotlin-gradle-plugin, it's possible to create a truly independent task that calls the compiler freely. On the side of reducing unnecessary KSP tasks, let me figure out how to create the task only when the
ksp()
configuration is there. Currently a task is created for each compilation task, but it does nothing without ksp configuration specified.
z
I saw the upstream bits - is there a timeline for that? Or would you consider using reflection to access them and allow for mixing?
t
We planned to upstream some patches but no timeline yet. It might be possible by reflection or working around kotlin's
internal
by calling from java . Both of them could be very hacky though.
z
gotcha. Are there public issues/PRs for these?
t
No issues yet. The patches will be part of the refinement (to get rid of accesses to internal classes / functions) of the incremental processing implementation. After that, it should be straightforward to create an independent ksp task.