Move to bindgen?

[kallisti5]

haiku-sys might want to consider migrating to bindgen.

https://docs.rs/bindgen/0.59.1/bindgen/

Essentially the bindings are auto-generated for you based on headers.

A smallish example project putting bindgen to work is here:

• https://github.com/storj-thirdparty/uplink-rust

I confirmed bindgen does indeed compile under Haiku.

[nielx]

Actually haiku-sys has been mostly (if not all) absorbed into libc, which is (infamously) manually maintained. Not sure if it makes sense to copy the efforts.

[sammoore]

@nielx is that also true of the Application Kit part as well? Would it make sense to use bindgen for the other kits in a separate lib (like this one) or am I missing something or thinking about this the wrong way?

[nielx]

@nielx is that also true of the Application Kit part as well? Would it make sense to use bindgen for the other kits in a separate lib (like this one) or am I missing something or thinking about this the wrong way?

It is my opinion that anything in the higher level kits (UI or otherwise) is fundamentally incompatible with Rust, both because the Haiku API is fully based on the OO model, as well as the fact that the borrow checker's rules are incompatible with ownership rules in the Haiku API.

I don't have any experience with other bindings, but I think there is a reasonably useful GTK binding, where I suppose the C-Style OO is better reproducible in Rust. I think there is also a Qt binding, but last time I checked that bound to the QML layer of the API. This is in line with other attempts of using Rust for UI toolkits, where it seems the binding is for a declarative UI API, and the rendering/drawing is deferred to a lower level OO layer (like a browser DOM)