Anyone out there do code gen? I want to generate kotlin (multiplatform) code from an xml schema and ...

# announcements

[Dominaezzz]

Anyone out there do code gen? I want to generate kotlin (multiplatform) code from an xml schema and need guidance on project structure.

[Nikky]

https://github.com/square/kotlinpoet
#C5HT9AL7Q

[Nikky]

to ive guidance on project structure i think one needs to know a bit more about what you intend to do.. do you want to generate code in a runnable jar, gradle plugin, idea plugin ?

[Nikky]

either way it would make most sense to have your code generation all in one gradle subproject and reuse it for gradle plugin and runnable jar

[Dominaezzz]

I want to generate an OpenGL function loader from the https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/gl.xml?raw=true

[Dominaezzz]

gradle plugin? For code gen?

[Nikky]

well it can invoke the code gen through a task or when the plugin is applied

[Nikky]

write the code in eg build/generated-src/main/kotlin and register it as source root

[Dominaezzz]

Ah I see. Would it make more sense to ship a gradle plugin that generates the loader?

[Dominaezzz]

Instead of shipping the generated library.

[Nikky]

well depnds on how you want to use it, or expect it to be used, i would do that only if it is quickly changing

[Nikky]

i would probably make a gradle plugin in buildSrc and use it to generate the library

[Dominaezzz]

It barely changes, especially since vulkan is a thing now.

[Dominaezzz]

I'll look into making a gradle plugin subproject then.

[Nikky]

i assume you know how to operate kotlinpoet already, otherwise.. its pretty simple and well documented in their repo

[Dominaezzz]

Yeah, I've used it before.

[Nikky]

gradle subprojects cannot apply each other.. the only way to do that is to have it in buildSrc

[Dominaezzz]

Oh

[Nikky]

here is how you can register a gradle plugin in buildSrc: https://github.com/DaemonicLabs/Voodoo/blob/master/buildSrc/build.gradle.kts

[Nikky]

it genertes some stuff but is not completely what you need

[Nikky]

and here is a better plugin example.. it registers multiple source folders,
the selected lines ensure that kotlin and idea plugins are applied: https://github.com/DaemonicLabs/Voodoo/blob/master/plugin/src/main/kotlin/voodoo/VoodooPlugin.kt#L26-L27

[Nikky]

it calls poet outside of anu task, that mkes it execute every time the plugin is applied, eg. on every build

[Nikky]

i hope you can puzzle together something useful 😛

[Dominaezzz]

Thanks!

[Nikky]

if you want to reuse the codegen anywhere else it would make most sense to split it into 2 projects and have the codegen deploy to maven and the gradle plugin bit can depend on it

[Nikky]

if not it can go into buildSrc/someSubProject

[Nikky]

is the project public anywhere ? is the codegen part is working i could try to PR the gradle plugin stuff

[Dominaezzz]

Hmm, I don't see myself using it elsewhere but thanks for the tip.

[Dominaezzz]

The project is public but I've only just started the codegen bit,

[Dominaezzz]

It's here https://github.com/Dominaezzz/kgl, I'm planning on adding a kgl-opengl subproject that'll depend on the plugin in buildSrc.

[Nikky]

well i am interested in implementing the gradle code.. poke me when you think its enough to get something started
eg. i can call the codegen and get some classes output

[Dominaezzz]

Ah okay, will do.

[Nikky]

wel lthere be more subprojects or just that one ?

[Nikky]

because i think it might be easier to have just one root module in the main project

[Nikky]

unless you plan to add other graphics wrappers

[Dominaezzz]

I'm only really planning to do code-gen for vulkan and opengl.

[Nikky]

oay so multiple modules.. and i should have looked at it..

[Dominaezzz]

Oh, do you mean move the code gen from buildSrc to an additional module?

[Nikky]

a submodule of buildSrc, i am not 100% sure its possible.. but i think it would be

[Nikky]

that way it is easier to move if you want to.. and seperate fro mthe plugin code and seperate from other codegen stuff you might add later

[Nikky]

although they can surely depend on some shared 3rd module.. once you see similarities that can be factored out

[Dominaezzz]

Ah I see. I only just learnt of buildSrc today from you. So I'm not to confident in decisions 😅.

[Dominaezzz]

There will be a lot of similarities.

[Dominaezzz]

Will splitting them into separate modules give me anything. I was planning on having two packages in the same module.

[Nikky]

https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources

The directory buildSrc is treated as an included build. Upon discovery of the directory, Gradle automatically compiles and tests this code and puts it in the classpath of your build script

[Nikky]

basically buildSrc on its own can be a normal gradle project, but because itsnamed like this and placed correctly it will be used i nthe build process of another gradle project

[Nikky]

nothing much, except seperation of concerns

[Dominaezzz]

Ah I wish I knew about this ages ago. Would be so useful.

[Nikky]

and maybe buildtime speedup with the correct options enabled becuse some modules might not change, not need to be recompiled

[Dominaezzz]

This might be a silly question but can I test the codegen without applying the plugin?

[Nikky]

generally i use it for just a few files, Constants, Versions, sometimes on a really complex project i use it like this: subProjects { configurrProject(this) }
where configureProject is a function with a big when switch in buildSrc

[Nikky]

in buildSrc ? i think so.. add application plugin, application { mainClass = ".." }

[Dominaezzz]

Oh! Silly me lol.

[Nikky]

idea will add buildSrc to your gradle sidebar:

https://i.imgur.com/9k6jp8p.png▾

[Nikky]

and you should be able to run any tasks on it

[Nikky]

did you know idea can even manage multiple gradle projects at once ?
in my case i have a samples subdirectory that applies the plugin from mavenLocal() for testing purposes

[Dominaezzz]

Oooh, didn't know that. That's pretty cool.

[Dominaezzz]

I forgot one can stick a top level main function anywhere and IntelliJ will offer to run it.

[Nikky]

yeah thats most likely going to be enough for pure testing, except if you add something that needs to be generated by a gradle plugin.. like kotlinx-serialization but thats another story

[Dominaezzz]

So I've pushed some of it to this branch https://github.com/Dominaezzz/kgl/tree/opengl . At the moment it does code gen during configuration phase (Which I know is bad but don't know enough about gradle to do the right thing lol).

[Nikky]

well actually not so bad, since thats gonna happen on every build at least, but maybe better would be to wire it up to always run before compileKotlin

[Nikky]

is there anything holding kgl back on gradle 4.10.2 ? gradle 5 would make it a bit easier to configure some things

[Nikky]

so i have successfully split this up in 2 tasks.. one to download the xml and the other one generates the source

[Nikky]

problem is now triggering that task before the kind of compile you want.. this one seems to only do mingw generation, thats windows right ?

[Nikky]

is there different things to be performed for jvm, js and native ?
then you can create different tasks and have those call common generator code
the different tasks are then gonna make sure the jvmMainClasses, jsMainClasses and whatever native uses are dependent on them
its not a problem to set up, i am just not sure how its gonna be
and i am on a linux laptop so the windows mingw stuff is not being set up for me i think

[Nikky]

if it is just always the same code then you might as well just make it a function thats not part of a plugin and call that with the generate-src and whatever other arguments

[Nikky]

Target 'mingw' for platform mingw_x64 is ignored during build on this linux_x64 machine. You can build it with a mingw_x64 host.