[Request]: Use new libsql-c bindings and dynamic linking

[jmatsushita]

What do you need?

Hi,

I'm following up on expo/expo#33644

I see that @levydsa at libsql has been working on another set of c bindings https://github.com/tursodatabase/libsql-c which seems to be able to generate a dylib and which they seem to use for their swift bindings although they generate static bindings for ios right now it seems like that would be a potential starting point? What you think about it compared to your work in their main repo?

@levydsa do you think it would be difficult to enable generating dylib for ios with libsql-c?

I realise that adapting op-sqlite to use these new bindings means quite a bit of work to adapt https://github.com/OP-Engineering/op-sqlite/blob/main/cpp/libsql/bridge.cpp and integrating (possibly a new xcframework) with the dylib. Do you foresee some other obstacles @ospfranco ?

if you're open to a PR, I wouldn't mind giving the more mechanical side of the work to claude and testing if you can spare some time on reviewing the work.

On a side note, if I manage to get some momentum with this, I might give a crack at update hooks an op-sqlite reactive queries given that there's now https://github.com/tursodatabase/libsql/pull/1839/files

Cheers,

Jun

[ospfranco]

Creating dylibs for iOS is not the same as creating them for macos, here is a write up on how to do it:

https://ospfranco.com/generating-a-xcframework-with-dylibs-for-ios/

More than the lack of how to, it's time and also changing the process with the turso folks. I've left them with a guide on how to compile the lib on every new release but this process is way too complex for every single release, so ideally this would be automated somehow and we can do it from here or from their end. But it requires coordination with @haaawk

[ospfranco]

I first need to tackle #202, that has already sponsoring and then I could tackle this but schedule is packed. Feel free to give it a stab if you want to. Ideally I would move away from a manual process and create and pack the xcframework in a github action inside of op-sqlite that way everything is self contained in this repo. Unless the turso folks also find it useful to generate it for their bindings.

[haaawk]

This is not ready yet. I will let you know when then new bindings are ready @ospfranco

[ospfranco]

Awesome. @jmatsushita let's keep things clean, create another ticket for the update hooks.

[jmatsushita]

This is not ready yet

@haaawk can you explain a bit more about how things are moving? Is the libsql-c repo the one to follow? Are you going to tackle building the dylib for ios in CI? Do you have some ideas of timelines and the priority for this work on your end?

here is a write up on how to do it

Very nice. I think I was close with my initial attempt.

pack the xcframework in a github action inside of op-sqlite that way everything is self contained in this repo

Yes that makes most sense.

we can do it from here or from their end

I'll wait to hear from turso about their plans before putting more effort into this.

[ospfranco]

As confirmed by Kudo in the expo thread, converting to dylib won't solve the conflict. In fact linking the dylib will just increase the size of the final bundle. I will close this as it won't solve the issue. For the new bindings, feel free to create a new ticket for it once they are out.

[haaawk]

This is not ready yet

@haaawk can you explain a bit more about how things are moving? Is the libsql-c repo the one to follow? Are you going to tackle building the dylib for ios in CI? Do you have some ideas of timelines and the priority for this work on your end?

libsql-c is ment to be the new bindings but we need to finish them and test them properly. They are used in Swift and Android SDKs but we need to switch Go SDK to it too. Once it is more battle tested we will probably migrate op-sqlite too.

[jmatsushita]

Thanks a lot @haaawk 🙏