-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility with Anvil #207
Comments
I don't think running another compiler plugin in the task created by KSP (or any other plugins) is a good idea. They should probably avoid this and only run in the main compilation task. |
Like I mentioned in the Anvil ticket this issue is related to KSP. It's bad if KSP breaks existing compiler plugins and also breaks APIs provided by the Kotlin compiler. |
Not fixable or even workaround-able in KSP. kotlin-gradle-plugin loads compiler plugins in the configuration phase by adding them to compiler classpath. Therefore all compiler plugins are loaded in all compilation tasks, including the custom ones in KAPT and KSP. It can be worked around in ComponentRegistrar in Anvil; Subplugin options are only passed to standard compilations and Anvil has a chance to not register itself. |
I'd like to repeat that this issue is not related to Anvil, but every compiler plugin out there. I tested it with two other compiler plugins and can reproduce the same issue. Is your plan to reach out to every plugin author and tell them to not use use certain APIs?
Older KSP versions didn't have this issue. One option is to revert the custom KSP task. You also have full control over the custom Gradle task that you create. As the author you control the inputs and outputs of your task. |
A custom compilation task is nothing strange. kapt also does it. Anvil happens to work only because it expects to work with kapt. Tell me how you can opt out for compiler plugins that don't expect to be launched int kapt's stub generation task.
Only if you write the plugin ground up, i.e., without using kotlin-gradle-plugin at all. Anyway, I'm checking with upstream to see if we can change the kotlin-gradle-plugin a little bit to only add plugin classpaths in standard compilation tasks. |
That would be great. In my opinion this should happen in the Gradle plugin and not in the compiler plugin. The compiler plugin shouldn't know anything about the build tool, that's the wronger layer. In fact, there's an API that seems to built for this, but it doesn't work on a task level but on a Gradle module level, which is quite unfortunate. |
Is there any known work around right now? |
Some of the plugins need to run within KSP's tasks, such as AllOpen, and some don't. The final solution would be letting users (who applies the plugins in their build script) to decide which compiler plugins to enable in KSP's task. That would need some patches to be upstreamed in kotlin-gradle-plugin, as most of the relevant flags / properties are marked internal. For now, I'm working on a patch to switch them all on or all off and hoping to land it before next release. Default will be off. |
Workaround landed in #270. Note that compiler plugins are enabled by default as KSP now copies all options for them from the main compilation. Unfortunately, that also means that there is no way to tell from compiler plugins whether they are in the main compilation or customized compiler invocation now. But at least this matches KAPT's behavior and hopefully most other compiler plugins won't break. Just in case, they can also be blocked by setting |
KSP seems to interfere with Anvil (https://github.com/square/anvil) compiler plugin, causing it to not compile with rather irrelevant (to you KSP developer) error message. I filled an issue with Anvil repo and they said
Here is a repro https://github.com/ursusursus/AnvilRepro2/blob/master/app/build.gradle
(I also tried the latest KSP version, same issue)
The text was updated successfully, but these errors were encountered: