:question: I have been working on a <gradle plugin...

# compiler

[Deactivated User]

❓ I have been working on a gradle plugin to support including IR plugins in gradle submodules for a project, without requiring separate gradle plugins. Similar to what KSP does, but for arbitrary IR plugins. It is working already, but I have not published it to central yet. Do you know if there is anything already for that or some efforts in that direction, to avoid doing it twice?

[raulraja]

Hi Carlos, We do something similar in Arrow Meta for IR but not in gradle. Wrapping the compiler api in a simple api for Ir transformations and soon FIR transformations to. We are waiting for stable FIR to release stable. We still have one gradle plugin for compiler plugin though.

[raulraja]

We tried a single gradle plugin approach but it gets messy because each compiler plugin runtime libraries may not be directly linked as dependencies but you may want to add them directly in the user sourceset classpath, and different plugins had different requierements in terms of dependencies and sometimes gradle setup

[Deactivated User]

I see, thanks for the reply Raul,

In this case Im resolving the artifacts in the gradle plugin, then creating a classloader from it. I won't need plugins depending on other plugins for this specific scenario but I guess that should be also supported.

My main problem was that I have a multimodule project and I want to use one module as a plugin, and other modules using it in addition to provide those plugins to consumers of the libraries. And I didn't find a no hacky way to do that with a raw plugin or KSP since I need to modify IR code.

[jw]

The plugin looks quite complicated. And this line suggests you haven't tested on native builds since you have to compile all plugins twice (once for native, once for all other targets) due to class relocation: https://github.com/korlibs/kirpter/blob/628274be5334f4aeaa4f51581d6b2dc3077d24e5/kirpter-gradle-plugin/src/main/kotlin/com/soywiz/kirpter/gradle/KirpterGradlePlugin.kt#L28

There are already configurations that you can add plugins to which are created by the Kotlin Gradle plugin. We copy/paste around this snippet to use compiler plugins without creating a whole `KotlinCompilerPluginSupportPlugin`:

targets.all {
      compilations.all {
        val pluginDependency = if (this is AbstractKotlinNativeCompilation) {
          project(":zipline-kotlin-plugin-hosted")
        } else {
          project(":zipline-kotlin-plugin")
        }
        // Naming logic from <https://github.com/JetBrains/kotlin/blob/a0e6fb03f0288f0bff12be80c402d8a62b5b045a/libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/plugin/KotlinTargetConfigurator.kt#L519-L520>
        val pluginConfigurationName = PLUGIN_CLASSPATH_CONFIGURATION_NAME +
          target.disambiguationClassifier.orEmpty().capitalize() +
          compilationName.capitalize()
        project.dependencies.add(pluginConfigurationName, pluginDependency)
      }
    }

(Apologies for the Gradle KTS 🤮 )

If you are only building for one platform it becomes even easier, like

import org.jetbrains.kotlin.gradle.plugin.KotlinPluginKt

dependencies {
  add(KotlinPluginKt.PLUGIN_CLASSPATH_CONFIGURATION_NAME, deps.compose.compiler)
}

[Deactivated User]

What makes you believe that the plugin is complicated?

I will check your gradle snippets later this week.

I thought that since Im targeting 1.6.0-RC2 and K/N was merged into the codebase, that it might work. I will create s sample covering multiplatform to check that, thanks for letting me know.
It is just class relocation or the API changes?
Would for example work like doing an ASM fqname class transformation in a separate class loader for the native part to avoid having to compile the plugin twice?

[jw]

What makes you believe that the plugin is complicated?

The fact that it is itself a Kotlin compiler plugin with a whole API when you can already accomplish this using the Kotlin Gradle plugin's built-in configurations, the standard APIs, and leverage the same Gradle dependency resolution semantics by participating in that.