Hi folks, how are you doing? Sorry if this isn't t...

# gradle

[Rafael Tonholo]

Hi folks, how are you doing? Sorry if this isn't the correct channel to ask this question, but it is related to both KMP, KGP and Kotlin Compiler Plugins. I've added some context after the question.

My question is: Is there a way to create a new KMP target and make sure a Kotlin Compiler Plugin will trigger both FIR and IR phases without the workarounds I've done (see context below)?

Ideally, I would also like to avoid suppressing some internal API usages I needed to do to make it work.

The main idea of the project is to create a target that would allow game developers to use Kotlin to work with both GDScript and, eventually, GDNative. However, I'm focusing only on GDScript for now.

---

Context:

I'm currently working on a Kotlin to GDScript transpiler, using a similar approach as Kotlin/JS does.

One thing I was really wanting was to create a new KMP target using the KGP, so I could prevent developers from using KMP libraries that do not have a godot target.

I was able to create a target from scratch. KGP detects it as an actual platform target; however, I was not able to trigger the compiler plugin phases nor generate a klib.

The only way I was actually able to do that was by creating the new target by extending KotlinJsIrTarget, but that forced me to write some FIR checkers to mark the usage of some Kotlin/JS function as an error, and strip out some default dependencies added by the target.

Thanks in advance.

[hfhbd]

Keep in mind, there is no support for custom targets. Even if you are able to do it once, it might break anytime.

[Rafael Tonholo]

Yeah, I know that. That is the reason I'm asking the question here, to understand:
• If it is at least possible; kind of it is, as I'm already doing it, but in a better/safer way
• And why not? I believe that would only help KMP to grow

[hfhbd]

Well, I would love to see it too, but for full support of arbitrary targets, you need to adjust KGP, BTA, Compiler, the Stdlib + native runtime, analysis api and also IntelliJ for IDE support.

Some people also tried to add Python and .Net or C++ support, eg you can take a look at #C01EY9ZF9B5

[Rafael Tonholo]

If BTA is Byte-to-Assembly, for my first case that won't be necessary, since the Compiler is transpiling the Kotlin to GDscript already. The stdlib (the core necessary, via polyfills), and IntelliJ support is already working

[Rafael Tonholo]

The KGP target configuration is the part I'm trying to figure out without doing workarounds

[hfhbd]

KGP uses BTA (Build Tool API) to invoke the compiler. But you don't need BTA, I just listed it for the full picture, you can call the compiler without BTA.

[Rafael Tonholo]

Okay, maybe, then, was the BTA the part I was struggling to make it work when I was setting up the KGP from scratch... Is there anywhere I could be looking for to find more information to either property setup it or to enable the compiler to be triggered without it?

[tapchicoma]

How does exactly this transpiler works? Is it a custom Kotlin compiler backend?

[Rafael Tonholo]

It is a custom Kotlin compiler plugin that uses both FIR and IR. The transpilation happens mainly on IR

[Rafael Tonholo]

It basically navigates through the IR AST and creates a GDScript AST, which later becomes the transpiled GDScript

[tapchicoma]

so I could prevent developers from using KMP libraries that do not have a godot target.

What is the actual limitation here? Only be able to use specific JS (?) API?

[Rafael Tonholo]

What is the actual limitation here? Only be able to use specific JS (?) API?

There are actually a few limitations:
1. The use of Kotlin/JS specific APIs
2. The usage of external declarations that would map to JS modules; I do support external declarations, but via annotations since I can't use the external keyword
3. Usage of third-party Kotlin/JS libraries, which would be very problematic since the platform APIs differ.

[tapchicoma]

so basically you want something like nodejs() or browser() , but for GDScript

[Rafael Tonholo]

Maybe? However, there is also GDNative that I could be supporting in the future, which would be a native target.

It's worth mentioning that GDScript is not related at all to any browser languages, so using a JS target would be conceptually wrong...

[tapchicoma]

and your compiler plugin works with any Kotlin platform or only JS?

[Rafael Tonholo]

I think it works. If I recap well, I've started making it a native target, but since Konan download a ton of things and I won't actually need to build any binary, the "cheapest" way was to go with JS.

Declaring the target using the KotlinPlatformType.common doesn't work, though, since it was not triggering the IR

[tapchicoma]

and would be you ideal way? Developing special Kotlin compiler backends for GDScript/GDNative and have it as a pluggable target in Kotlin?

[Rafael Tonholo]

If I understand you correctly, I’d say: define one or two targets (following Android and androidNative) that support common APIs through commonMain and `actual`/`expect`, then add these targets to be pluggable into KGP or Kotlin toolchain (preferably).

Then, if the target plugin is added to the project classpath, KGP or Kotlin toolchain would enable them to be used

[Rafael Tonholo]

And, ideally, let GDScript target also use expect, but I can live without it and keep using the annotation's approach