How are ksp gradle tasks included into other assem...
# ksp
m
How are ksp gradle tasks included into other assemble tasks? My library relies on kspCommonMainMetadata being run. For me it's run for KMM's embedAndSignAppleFrameworkForXcode but for another person it's not. How can I debug such an issue?
j
ksp is added to each compile task, and it depends on your project to determine what’s the compile task name, and its bundled assemble task name.
m
j
You should get the dependency correctly out of box, what’s the purpose of this function? Also if you want to get the full picture of your build, can you try run
./gradlew build --dry-run
to get a full list of tasks?
m
It's a library and this line is from its compiler plugin. The library generates commonMain source code and then applies it as a source set for the ios target (its name is provided by the plugin extension). So it needs to run kspCommonMainKotlinMetadata before ios compilation because ios compilation will use the generated source. I assume that for kmm project kspCommonMainKotlinMetadata task has to be run always, commonMain is part of every project, right? So the problem might be the order of compilation, not that this step isn't run at all?
(I know it's a bit unorthodox usage of ksp but we don't have full multiplatform support yet, different methods caused the same source code generated for different source sets which compiler marked as redeclaration)
j
that’s what I was wondering..
commonMain
has to be run before
ios
target, so you should get the correct ordering out of box
m
Hmmm I think I added this function after having issues, but it's been a few weeks and I'm not quite sure now. Anyway, that might be an overkill but should not cause any problems, I think. Still, one of the library users reports that the sources are not generated (not even the generated/ksp folder appearing) when using embedAndSignEtc... and I don't quite understand what might be missing.
j
hard coding task name in build script to force ordering might not be a good idea to begin with, because the task name is subject to change depending on the actual project consuming your plugin.
can you try to ask the user reporting this issue to run a dry run of gradle build to get a full picture of their tasks? Might find the missing task there.
m
I'll try that, thanks :)
As for hard coding task names, I'm following this thread and counting on official multiplatform support, that's gonna be a game changer for me
133 Views