I suppose the next question is: how do you make a ...

# compiler

[Caleb B]

I suppose the next question is: how do you make a compiler plugin that works both in a project and in the IDE, if the IDE is always on a different compiler version from the project but tries to use the same artifact?

[Youssef Shoaib [MOD]]

I think those versions are technically accessible from a special dev repository (can't find the link rn cuz on mobile), meaning you can test against them if you want. Metro, being arguably the most robust third-party plugin, does such multi-version testing (although I'm not sure if they do it just for different Kotlin releases or also for the versions that the IDE uses)

[Caleb B]

I mean in terms of artifact usage. Do I just have to make sure the same plugin artifact works on multiple compiler versions at once?

[Caleb B]

Or is there a way to tell IJ to use a different artifact? Like different "target compiler version" Gradle attributes?

[Caleb B]

I'm extremely used to dealing with constantly-fluctuating APIs, I just want to make sure I can actually keep them in two separate artifacts instead of having to invoke everything with reflection to make the same artifact work in two places.

[Youssef Shoaib [MOD]]

There doesn't seem to be a simple "pick the version of my plugin based on the compiler version" mechanism. However, there's some way to get the compiler version at runtime, and so you can do runtime checks, and based on that call the apt method. From what I read (well,

watched▾

), Metro does this with runtime version checks and a service loader to load the right compatibility object without referencing it directly

[Caleb B]

oh god

[Caleb B]

alright, thx