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

Add support for variant aware KSP arguments #861

Open
runningcode opened this issue Feb 21, 2022 · 10 comments
Open

Add support for variant aware KSP arguments #861

runningcode opened this issue Feb 21, 2022 · 10 comments
Labels
api API changes may be involved

Comments

@runningcode
Copy link
Contributor

I would like to provide variant specific KSP arguments. For example, I would like kspDebug and kspRelease to have different arguments.

An example use case is Room or DeepLinkDispatch. Both are kotlin symbol processors which write output to a directory. The directoy must be task specific so that kspDebug and kspRelease do not write to the same directory. Two tasks which write to the same directory disable up-to-date checks and caching in Gradle because the build becomes non-deterministic.

For reference, Java annotation processors and KAPT both provide a way of passing task specific arguments to the annotation processors.

@ting-yuan ting-yuan added the api API changes may be involved label Mar 3, 2022
@ting-yuan
Copy link
Collaborator

One solution might be exposing variant info to processors and let them pick the arguments but I'm sure there are better ways. Can you share what KAPT and Java annotation processor's approaches are?

@ting-yuan ting-yuan added this to the 1.0.5 milestone Mar 4, 2022
@runningcode
Copy link
Contributor Author

Good question. KAPT pulls them out of the java annotation processor options here

The Gradle Java plugin has a way of passing compilerArgumentProviders via the dsl.

I think we need to think about how all these work holistically. The approach that KAPT had to pull the arguments from the javacompile options might not make sense for KSP since the arguments would not affect the outcome of javacompile tasks nor KotlinCompile tasks.

We should also think about this in concert with this PR.

@neetopia
Copy link
Collaborator

should this be closed now that linked PR is merged?

@ting-yuan
Copy link
Collaborator

Nope, the merged PR is related but not solving this.

@runningcode
Copy link
Contributor Author

This also probably needs to be resolved first before a variant aware API compatible with the latest versions of AGP can be created: https://issuetracker.google.com/issues/223367107

@neetopia
Copy link
Collaborator

I might not have full context on this issue, what's the current status?

@runningcode
Copy link
Contributor Author

Forget my comment above. It is not needed since we will not be passing arguments from AGP's CommandLineArgumentProvider to KSP.

This issue to add support for variant aware KSP arguments has no status update.

@neetopia neetopia modified the milestones: 1.0.6, 1.0.7 Jun 7, 2022
@ting-yuan ting-yuan removed this from the 1.0.7 milestone Oct 12, 2022
@TomBell-Trove
Copy link

Would love this. I want to pass an arg to my processor which varies based on my Android build variant to alter its behaviour during production builds.

Is there a workaround to achieve this in the meantime? It seems that just plonking a differing ksp() in each variant's block isn't enough, the final invocation wins.

@nak5ive
Copy link

nak5ive commented Aug 14, 2023

I may have a workaround for this.

KSP offers the ability to get information about files it creates via the CodeGenerator.generatedFile collection (warning: completely undocumented). I was able to pull information about the current variant / sourceset by inspecting the path data after creating a marker resource file. something like:

private fun CodeGenerator.collectVariantName(fileName: String): String {
  createNewFileByPath(Dependencies(false), fileName, "txt")
  return generatedFile.first().run {
    val (variantName) = Regex("ksp/(.+)/resources").find(absolutePath)!!.destructured
    variantName.replace("UnitTest", "")
      .also { writeText(it) }
  }
}

Having to generate a dummy file isn't great, but it works. Call it at the top of process() and then you can pick a name-spaced argument, like:

ksp {
  arg("some.argument.debug", "debug value")
  arg("some.argument.release", "release value")
}

I raised an issue to expose some config data to the processor that would hopefully make this sort of workaround unnecessary.

@kazemcodes
Copy link

I may have a workaround for this.

KSP offers the ability to get information about files it creates via the CodeGenerator.generatedFile collection (warning: completely undocumented). I was able to pull information about the current variant / sourceset by inspecting the path data after creating a marker resource file. something like:

private fun CodeGenerator.collectVariantName(fileName: String): String {
  createNewFileByPath(Dependencies(false), fileName, "txt")
  return generatedFile.first().run {
    val (variantName) = Regex("ksp/(.+)/resources").find(absolutePath)!!.destructured
    variantName.replace("UnitTest", "")
      .also { writeText(it) }
  }
}

Having to generate a dummy file isn't great, but it works. Call it at the top of process() and then you can pick a name-spaced argument, like:

ksp {
  arg("some.argument.debug", "debug value")
  arg("some.argument.release", "release value")
}

I raised an issue to expose some config data to the processor that would hopefully make this sort of workaround unnecessary.

#1850 is it possible to also get project directory using your code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api API changes may be involved
Projects
None yet
Development

No branches or pull requests

6 participants