Is it possible to leverage ksp to generate non kot...

# ksp

[Paul Woitaschek]

Is it possible to leverage ksp to generate non kotlin code?
I'd like to leverage the symbol processing to generate swift files

[Big Chungus]

Can't see why not. Just write them via jvm File api

[Paul Woitaschek]

But that breaks incremental things right?
How would I know which files to delete and which ones to keep?

[Big Chungus]

Oh you mean you want to fully replace some kotlin files with swift?

[Paul Woitaschek]

No of cause not 😛
But right now when I generate a file based on a kotlin file and compile, the generated file gets created.
When I now delete the originating file and compile, the generated file will also be deleted.
But that step wouldn't happen when I just use the file api so dead generated files will be left I guess?

[Big Chungus]

Just write a file to different dir not controlled by ksp. You can pass on the path via ksp gradle options

[Paul Woitaschek]

But how would I know when to delete the file?

[Big Chungus]

It won't. That's for you to manage either manually or with a gradle task

[Paul Woitaschek]

But how could I possibly know that?

[Big Chungus]

Keep your own cache during generation maybe? Could be as simple as storing a json map of kt sources ang generated swift files. Then at the end of each ksp task compare the new such map with previous one and clean up

[Big Chungus]

In short, generate map during ksp, compare new map with cached one in your custom gradle task (or doLast {} block in ksp task), cleanip and move new map to cache

[Paul Woitaschek]

But what would be in that map?

[Paul Woitaschek]

On incremental rounds, the ksp allFiles() will only contain the changed ones

[Big Chungus]

{
  "path/to/source.kt": "path/to/geterated.swift"
}

[elect]

I used KSP the other day to generate plain java sources. The previous implementation was using Apache Velocity, Kotlin proved extremely nice

[Grégory Lureau]

Why not just using CodeGenerator.createNewFile(Dependencies(false, false, listOf(“source.kt")), .., extensionName = "swift") ?

[Paul Woitaschek]

Because that would put it in the kotlin sourceset?

[Grégory Lureau]

Mmmh, from memory it goes into a resource directory

[Grégory Lureau]

Not finding the documentation right now, but an extension ".kt" goes into /kotlin, ".java" into /java and anything else I suppose will go into /resources

[Grégory Lureau]

Here's an example of associating not-kotlin files to one or multiple class declaration: https://github.com/google/ksp/blob/a38ac896fa80a659907485c02bfa688b7d79ca25/integr[…]es/incremental-classpath/validator/src/main/kotlin/Validator.kt

[Paul Woitaschek]

Uh that might work!

[elect]

open an issue, they are usually quite prompt to reply

[Paul Woitaschek]

Will do 🙂

[elect]

anyway, cool experiments Paul, keep us updated

[glureau]

Is it because the kotlin directory is removed (not normal but known bug AFAIK) and you still have an explicit reference in your build.gradle on this directory?

[Paul Woitaschek]

But what removes it?

[Grégory Lureau]

I was thinking about this feedback, I experienced the same behaviour myself https://kotlinlang.slack.com/archives/C013BA8EQSE/p1635931295085600

[Paul Woitaschek]

@elect

anyway, cool experiments Paul, keep us updated

Keeping you updated 😉
https://medium.com/@woitaschek/kotlin-native-using-swift-not-objective-c-d7742c040539

[Grégory Lureau]

Thanks ! Do you plan to open-source your tool? (I'm working on similar stuff from JS myself, and could be interested by this one too.)

[Paul Woitaschek]

I don't believe that it would work on a one-library-fits-all level.
It has many things specific to our language and also some exceptions for non generated code integration.
Also this only works because all our data structures are immutable. If you would generate structs from mutable structures that would probably lead to unexpected behavior.

[Grégory Lureau]

Exactly the same problem for JS, that's why I'm providing wrapper by defaults, so those forward everything (binding 2 ways, changing types in the middle)...