search

lit-robotics / libcamera-rs

Experimental Rust bindings for libcamera
Apache License 2.0
46 stars 15 forks source link

Multiple rust language bindings #3

Closed kbingham closed 1 year ago

kbingham commented 1 year ago

Hello, I'm very pleased to see development of rust bindings for libcamera.

I'm aware that there may be parallel developments ongoing, and that another implementation is at https://github.com/dennisss/libcamera-rs/

I see that denisss' repository has taken the rust-cargo libcamera namespace https://crates.io/crates/libcamera, and that worries me about how users will identify what the 'correct' rust bindings will be for libcamera.

How should we determine what the 'official' bindings will be for libcamera?

kbingham commented 1 year ago

See: https://github.com/dennisss/libcamera-rs/issues/1

chemicstry commented 1 year ago

Hi, thanks for noticing this.

I see that the other project uses cxx instead of bindgen, maybe that was the reason for starting a separate one? Or maybe just bad discoverability of this repository. I didn't want to squat crates.io package name before this project gained some traction, because dead crates are already a problem there.

In any case, I would be happy to join efforts on this.

kbingham commented 1 year ago

When asked about rust bindings, I've been pointing people to this repository so far.

But I'd really like to make sure any 'libcamera' crate name is well supported.

I hope that we'll get to making some more official C bindings soon, possibly based on the work you've done in here. I hope that will make it easier to build things on top of too.

dennisss commented 1 year ago

The motivation for my repository was that I was unable to find this repository on Google or Crates.io. I will archive mine so that this repository can stay the primary copy.

Mine uses both cxx and bindgen to avoid having to write a complete C API.

chemicstry commented 1 year ago

Yeah, I tried searching "libcamera rust" and couldn't find neither this crate nor an older issue about rust bindings in kbingham's libcamera mirror on github. Weird.

Anyway, thanks for transferring crates.io ownership. I would be happy to invite you as collaborator to this repository if you would like to co-maintain it.

I initially also started with cxx, but failed to overcome the initial headbanging barrier and switched to writing C shim. Looking at your code it does look simpler with cxx and it might make some API less awkward without having to use newtypes. I'm not sure if refactoring is worth though, especially if libcamera is getting official C API. Let me know what you think.

kbingham commented 1 year ago

Would you be willing to use gitlab and move the bindings to gitlab.freedesktop.org/camera/libcamera-rs ?

chemicstry commented 1 year ago

I have no problem with transfering this to gitlab or anywhere else in general, however, I have a lot of projects to tend to, so it's easier for me to have everything in one place (github). If there are other people who are also interested in maintaining this, then sure.

chemicstry commented 1 year ago

I will close this issue since it's no longer relevant.

But just to be clear I'm always open to moving it to official libcamera gitlab (or anywhere else official) if there is interest in taking over the project maintenance.

kbingham commented 1 year ago

Closing is reasonable.

The impasse currently is that the libcamera project can not operate on Github (github itself is a proprietary hosting solution, and the libcamera project strives to use only open source tools, all of my repos here are forks and mirrors only).

We can help you maintain the bindings if they are hosted on gitlab as an opensource hosting implementation, which is why I have suggested gitlab.freedesktop.org/camera/libcamera-rs - but you were not willing/desiring to participate or move there.

Meanwhile, we have little to no rust experience in the libcamera project presently so if we take it there without your support I'm not sure we have enough expertise in the community yet to actually provide any support or development. There's no value in moving the repository to somewhere where it will be ignored and left to bitrot.

Overall though, I would see identifying these bindings as 'officially' supported in some form would be a good path to explore, if we can resolve the above impasse.