Experience: Building bindings for rocksdb c++ API

[dignifiedquire]

I am using this as a collection of challenges that I run into, when building bindings for https://github.com/facebook/rocksdb/. The work is based on https://github.com/rust-rocksdb/rust-rocksdb/ but switching to cxx + autocxx for generating bindings instead of using bindgen to bind to the C api.

I apollogise in advance if this is the wrong place, and happy to put this somewhere else.

The good news: I have gotten things to compile and generate some bindings 🎉 Now for the challenges

• Most of the methods on DB are not actually generated, e.g. https://github.com/facebook/rocksdb/blob/main/include/rocksdb/db.h#L163-L164. The codegen gives me the error of autocxx bindings couldn't be generated: Pointer pointed to something unsupported
• Methods like https://github.com/facebook/rocksdb/blob/main/include/rocksdb/db.h#L180-L182 fail to be generated with autocxx bindings couldn't be generated: Type std::vector was parameterized over something complex which we don't yet support, which asfaiu is expected for the moment due to the challenges of working with std::vector in general.
• https://github.com/facebook/rocksdb/blob/main/include/rocksdb/db.h#L348-L350 fail to generate with autocxx bindings couldn't be generated: This function or method uses a type where one of the template parameters was incomprehensible to bindgen/autocxx - probably because it uses template specialization.
• I am currently only generating bindings for rocksdb::DB, when I switch to generate to generate bindings for the whole namespace, I ran into the following error: at 'calledResult::unwrap()on anErrvalue: InvalidCxx(Syn(Error("unsupported type: IOStatus_SubCode"))), which I suspect to be an issue with https://github.com/facebook/rocksdb/blob/main/include/rocksdb/io_status.h#L29 but not sure what autocxxs issue with it is exactly.

Code lives here: https://github.com/dignifiedquire/rust-rocksdb/tree/autocxx

[adetaylor]

Thanks for the experience report!

The last issue is probably something I encountered a few days ago too and have just finished reducing - there's a failing test case at #1074 which hopefully I'll diagnose and fix in the coming days. (No promises of course).

For the others - yeah, there are lots of kinds of types we don't yet support. As well as gradually increasing support for more kinds of types, it might be that we can instead start to treat unsupported types as opaque types, so you can at least receive them from one function/method and pass them back into another. There's currently no tracking issue for this. In due course I may open one.

[dignifiedquire]

@adetaylor any recommendations on how to work around those, e.g can I auto generate some of the methods that work and fill in the others by hand? or do I have to opt out for the entire class if some things are not supported?

[adetaylor]

With the exception of the last problem, which hopefully is fixed by #1074, you should still be able to generate the rest of the class. It should only reject/ignore specific methods which cause difficulties.

[tv42]

For Pointer pointed to something unsupported in the case of DB::Open, it's an "out parameter" so a pointer to a pointer, see #1361 (no solution at this time).