Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish Rust bindings on crates.io. #3

Open
hgaiser opened this issue Apr 28, 2024 · 4 comments · May be fixed by #11
Open

Publish Rust bindings on crates.io. #3

hgaiser opened this issue Apr 28, 2024 · 4 comments · May be fixed by #11

Comments

@hgaiser
Copy link

hgaiser commented Apr 28, 2024

Hey! I see you're making good progress on this :). The C API looks nice and clean from what I saw so far.

Do you have any plans on publishing the Rust bindings on crates.io? I have absolutely no idea if, or when I would like to add this to moonshine, but at the very least I would like to add it as TODO for someone to pick up.

A related question: do you have any plans to make a Rust wrapper on top of the bindings? I think they can be pretty straightforward and would help adoption in Rust :).

@ABeltramo
Copy link
Member

There's already a barebone Rust project under bindings/rust. I was mainly focusing on having a working build environment using bindgen.
I'd like to first wrap all the "unsafe" code and expose a nice Rust API so that it can be easily consumed, and then eventually publish it on crates.io

@hgaiser
Copy link
Author

hgaiser commented Apr 28, 2024

Great :) looking forward to it.

Ps. I like to use a bindgen script instead of building the bindings dynamically, like here. Saves another dependency ;)

@ABeltramo
Copy link
Member

That's interesting, what would be the difference between manually installing it with cargo and having it defined as a [build-dependencies] like I've done here? I kind of like that it basically does that step automatically for you when building the project..

@hgaiser
Copy link
Author

hgaiser commented Apr 28, 2024

The main advantage would be that it is one dependency less. However, for nvfbc-sys the header rarely changes so it makes more sense there. Since you're actively developing it, maybe it's better to have it build dynamically in build.rs :)

@ABeltramo ABeltramo linked a pull request Aug 3, 2024 that will close this issue
9 tasks
@ABeltramo ABeltramo linked a pull request Aug 3, 2024 that will close this issue
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants