Skip to content
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

Closed
ursusursus opened this issue Dec 22, 2020 · 9 comments
Closed

Compatibility with Anvil #207

ursusursus opened this issue Dec 22, 2020 · 9 comments

Comments

@ursusursus
Copy link

ursusursus commented Dec 22, 2020

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

The problem is likely that they create a custom Kotlin Compile task for which Anvil registers its compiler plugin. KSP then doesn't forward the compiler plugin flags for Anvil and causes this error. (square/anvil#171)

Here is a repro https://github.com/ursusursus/AnvilRepro2/blob/master/app/build.gradle

(I also tried the latest KSP version, same issue)

@ting-yuan
Copy link
Collaborator

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.

@vRallev
Copy link

vRallev commented Dec 28, 2020

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.

@ting-yuan ting-yuan added the wontfix This will not be worked on label Jan 21, 2021
@ting-yuan
Copy link
Collaborator

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.

@vRallev
Copy link

vRallev commented Jan 21, 2021

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?

Not fixable or even workaround-able in KSP.

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.

@ting-yuan
Copy link
Collaborator

ting-yuan commented Jan 22, 2021

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.

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.

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.

@vRallev
Copy link

vRallev commented Jan 22, 2021

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.

@chrisjenx
Copy link
Contributor

Is there any known work around right now?

@ting-yuan
Copy link
Collaborator

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.

@ting-yuan ting-yuan removed the wontfix This will not be worked on label Jan 25, 2021
@ting-yuan
Copy link
Collaborator

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 blockOtherCompilerPlugins to true in the ksp extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants