Create C bindings

[Johannesd3]

@d4rwel inspired me to write down some thoughts I had about creating C bindings for librespot. There's no need to change anything in librespot itself, it could happen in its own crate/repo. I assume that #665 is ready, but it could also be accomplished with git dependencies.

So here's a rough plan:

Create a rust library crate and add the following to the Cargo.toml:

[dependencies]
librespot = "<choose version>"
tokio = "<choose version>"

[lib]
crate-type = ["cdylib"]

Pick some important Rust functions from librespot. Maybe look at the examples to decide what's needed.

Create functions that are callable from C as shown in this gist, or rather this repository.

Important: Wrap everything into a catch_unwind. If an error occurs, there might be UB if it reaches the border to C.

There are certainly some structs that need to be passed. Since those structs are not compatible with C, they must be passed as opaque type behind a pointer (as in the example).

Some functions are async. These functions must be executed by a tokio runtime. Create functions to created and destroy a tokio runtime. Return this runtime as opaque struct. (This struct could even be called librespot if the user shouldn't be bothered with implementation details.) For every function call that executes an async rust function, a pointer to this struct must be passed.

Remember, destructors in Rust are implicit. It's important to create functions that deallocate resources again, although these functions seem to do nothing. Look at the example above.

If it's ready, running cargo build will produce a .so file in target/debug.

Run cargo install cbindgen to install a tool to create a C header file. cbindgen --lang c will hopefully spit out the expected result.

You can now write a C application that uses librespot. Just include the header and link it against this .so file.

How does it sound?

[sashahilton00]

I believe C bindings were discussed at some point a few years ago, but work never really progressed on them. My thoughts on it are limited since I have no need of them/plan to use them, though can understand why they might be useful. I think any development should happen in a completely seperate repository though, purely for separation of concerns.

[roderickvd]

To better understand your question, why do you feel it's important to be adopted by librespot-org?

[Thalhammer]

It isn't hugely important for me, but it feels like the right thing to do given it would probably be more or less a direct reimplementation of the existing libs, just in a new language.

[roderickvd]

I don't know about a policy nor is it up to me. But generally I'd say that all well-maintained ports would make good candidates.

[sashahilton00]

We can create a namespace and a team for the C++ version if that would be of interest. Only thing I would say is that it might be better to implement a basic version in your own repo, then assuming it gets to the point where it has enough functionality/stability to be considered a viable client/library, and you're happy to be the ongoing maintainer of that version, it can be transferred/renamed to librespot-cpp under the librespot-org organisation.

[Thalhammer]

Only thing I would say is that it might be better to implement a basic version in your own repo, then assuming it gets to the point where it has enough functionality/stability to be considered a viable client/library, and you're happy to be the ongoing maintainer of that version, it can be transferred/renamed to librespot-cpp under the librespot-org organisation.

Thats what I had in mind. I just asked beforehand because I noticed over time that some organisations seem to be quite reluctant against transfering in external projects, especially if its not in one of the "cool" and modern languages.