Add support for `windows_aarch64`

[BierDav]

powersync-sqlite-core just got support for windows_aarch64, please reflect that in the Kotlin SDK's build script too, so that we can run our application with native JDK.

This is the file that needs to be edited: https://github.com/powersync-ja/powersync-kotlin/blob/main/common/build.gradle.kts

[simolus3]

Unfortunately it looks like the Androidx bundled SQLite driver doesn't support Windows on ARM either, and we depend on that.

I can take a look at adding support for that at some point, but contributing to Androidx always takes a while and they have complex build setups. So if you need this, it may be worth filing an issue on their tracker and perhaps someone from Androidx can help with that part :)

[BierDav]

Gotcha, thanks for clarifying the depdency, I didn't know that. The issues actually already exists. I will leave it here for documentation: https://issuetracker.google.com/issues/426464784

[simolus3]

Unfortunately we can't reliably test this in our CI because the Windows arm image does not include an Android SDK, but the new com.powersync:sqlite3multipleciphers project is an alternative to androidx.sqlite:bundled-sqlite-driver that should support Windows on arm.

The linked pull requests also bundles the relevant build of the core extension. So from the next release, you could potentially use the encryption SDK to run Windows on arm (and now I wonder if we should make the key optional to support unencrypted databases with that package...).

[BierDav]

Nice 👌 is there a chance to get wasm support too? 🙈

[simolus3]

Now that's a much bigger project.

The hardest part of wasm support is probably not even compiling our SDK and linking the core extension. But convincing SQLite to run on the web efficiently is really tricky (we have experience doing that for our Dart and JS SDKs, I don't think we're going to repeat those efforts for Kotlin). Some hypothetical approaches might be:

• I know a web build for sqlite3 is in the works for Androidx, we might be able to use that. But another problem is multiple tabs, we'd need a custom shared worker to coordinate the sync process, update flows for watched tables and so on.
• We could potentially use our JS SDK as a starting point and write Kotlin bindings for that instead.

But I don't think we have plans for this at the moment. You can upvote this roadmap issue to signal your interest.

[BierDav]

Ok got it. Could you at least make the little portion that is already Wasm/JS compatible work? Because this would allow us to share the Schema definition between Kotlin for mobile and Kotlin/Wasm (where we use the Js/Wasm library)