Fix coroutines not being added to desktop:dist #6822
Conversation
There was a problem hiding this comment.
Yes, ALSOFT is a Linux OpenAL thingy.
And re Music - was just meant as trigger for joint brainstorms. Remember on desktop it doesn't use a timer, piggybacking on Gdx's main loop instead. Took me months to figure out - and to balance the decision which compromise to PR.
And runtimeClasspath + compileClasspath sounds very much like "that's it"
|
Say, coroutines - didn't they have specific requirements for androidx.work? And our work-runtime-ktx:2.6.0 is a bit old, but restricted by targetApi = 30. Is that enough for coroutines 1.6? |
Since this is a kotlin language feature/official library, I'm pretty sure this applies. |
The first commit in here is just the last coroutine PR. The second commit 38b3e14 is the interesting one.
For some reason that I don't care about, coroutine classes are only added to the runtime classpath, not the compile classpath. So I just simply add the runtime classpath to the files included in the jar. Which just makes sense, of course we want to have the classes that are required at runtime in the .jar that runs the program.
As for this: #6801 (comment)
Is this new with the coroutines or did this happen before? If it's happening only now, how do I reproduce it, i.e. which platform? It's not happening on Windows & Android (with this PR) as far as I can see.
I actually didn't check for
kotlin.concurrent.timer.Timer. It's just a simple thread, one can still use normal threads of course, same behavior as before, so leaving it should simply change nothing. I'll see if it makes sense and how to migrate all the timers.