[Question/Help Wanted] Running apt in the same sourceset while compiling it

[Archinamon]

Hi!

I've faced problem implementing APT with your library. Looks like it's normal behavior of kotlin's compiler, I dunno.

Project: mpp with common/frontend/backend source sets.

What I need? I have classes in backend source set, that should be weaved by my APT plugin.
And here is an egg-chicken trouble :) Kotlin code I generate with APT should be included in compiler on the current run...

On the first run APT works well, but rendered classes not includes in compiler and it fails with "Reference not resolved" error.
On the second run everything compiles fine, as compiler knows about rendered files already.

Any way this behavior could be achieved? :)

[chippmann]

We had the same problem on our project. We basically "solved" it by making a fake target through gradle at build time which has the same configuration like the actual target we want to build. During the compilation of the fake target, the generated code is created and added to the source set and thus available when the actual target is built.
An ugly hack but with the current way compiler plugins are made, it seems not to be possible to achieve this like with the kapt annotation processors for the jvm. The only other solution would be to directly generate IR for the kotlin compiler like the kotlinx Serialization plugin does. But then you end up with code that is not debuggable.
So a trade of either way.

Edit: from here on we create the dummy target: https://github.com/utopia-rise/godot-kotlin/blob/521476cececfa13cbc86cb3b9e7d9eb3a3bd15be/plugins/godot-gradle-plugin/src/main/kotlin/godot/gradle/GodotPlugin.kt#L73 if you want to have a look on how to setup this

[Archinamon]

Looks cool! But doesn't work on my side :(

The reason is: you made a virtual target with custom source set name (godot[Main|Test]).
But I have a jvm default source set.

Well, it still could be achieved with your's way. But I need to change whole project's structure :(

I'm digging deeper to kotlinx.serialization... What do you mean saying "directly generate IR"?

[chippmann]

Yes depending on the size of the project that's not feasible at all.
You can directly generate the Intermediate Representation (IR) of the code you want to generate. This is the format the kotlin compiler uses to generate the ByteCode for the various platforms.
But as of now this is very poorly documented and not a stable API yet. With Kotlin 1.4 it seems they want to improve that situation.
That said I'm by no means an expert on how to generate IR. On our project we'll start into looking to directly generate IR with kotlin 1.4 soon so not much experiance on my side. Your best bet seems to be the kotlinx.Serialization plugin.

Also a good starting point might be this set of slides: https://resources.jetbrains.com/storage/products/kotlinconf2018/slides/5_Writing%20Your%20First%20Kotlin%20Compiler%20Plugin.pdf
from this talk: https://www.youtube.com/watch?v=w-GMlaziIyo
Although he directly generates JVM bytecode from it, it might get you more familiar with what to look for.

But maybe @Foso has a better idea on how to tackle this problem which is quite similar with what i eluded here: #11
There i also linked another possible but really hacky "solution" by generating the code in advance of the compilation process by parsing kotlin code yourself with the help of the kotlin compiler frontend.
Shortcut if you don't want to read the issue: https://github.com/vektory79/kotlin-script-parser-test/blob/master/src/main/java/hello/CompileTest.kt

[Foso]

Hi, sorry for the late answer, unfortunately i don't have a better solution yet, but i will take a look if Kotlin 1.4.0 offers some new opportunities