On Mon, Jul 08, 2019 at 10:49:55AM +0200, Martin Kletzander wrote:
On Mon, Jul 08, 2019 at 10:10:10AM +0200, Pino Toscano wrote:
On Saturday, 6 July 2019 13:03:24 CEST Martin Kletzander wrote:
Just one thing, the Cargo.toml includes a version under which the crate would be published. I presume the version would be the same as the one of the project itself, i.e. when releasing libguestfs-x.y.z, we publish guestfs-rs-x.y.z to crates.io.
Speaking of naming: it seems like libraries that interface/wrap a foreign C/C++/etc library are usually called foo-sys -- so should our binding be named guestfs-sys?
So you've seen my RFC? =)
Just to guestfs-sys would be a crate that does only two things:
1) exposes the C functions using `extern`
2) links to the library
And then another crate (e.g. guestfs) would expose the higher-level, safe, hopefully idiomatic API. More information (reasoning etc.) see:
https://doc.rust-lang.org/cargo/reference/build-scripts.html#a-sys-packages
For the Python guestfs bindings we originally planned to write an idiomatic (ie. OO in that case) API on top of the raw generated bindings, but never really got around to it. I'm not convinced it's really a good idea because you end up chasing new APIs. Remember the whole point of the generator is that new APIs are instantly available in all languages as soon as they are added upstream. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top