search

aldanor / hdf5-rust

HDF5 for Rust
https://docs.rs/hdf5
Apache License 2.0
310 stars 85 forks source link

Use bindgen for C binding #100

Closed swfsql closed 4 years ago

swfsql commented 4 years ago

Hello! I was trying to use this crate and I noticed that it's behind the greatest n latest 1.12 https://github.com/aldanor/hdf5-rust/issues/94

I actually don't know the library (nor what were changed - structure/behaviour/etc), but I imagine that dealing with multiple versions (and possibly multiple OS) would be eased if the bindings were to be generated automatically.

I noticed a discussion on https://github.com/aldanor/hdf5-rust/issues/28 about "interesting behaviours", and I couldn't tell if a bindgen outputs would work out-of-the-box.. I started a little bindgen test on my pc, and that type hbool_t ended up being just bool on my pc (win10 x86_64 msvc) - but I don't know if this is correct or not, or what interferes with what.

Well, that being said, I'll try turning bindgen on and see what fails and clean it.. then I think it could work as a draft pr

aldanor commented 4 years ago

@swfsql If you look at the hdf5-sys, you'll find many details like chunks of bindings being turned on-and-off at compile time depending on HDF5 version and its features enabled (like MPIO, etc). Also, there's hacks around C names in Windows dlls (__imp_*) and a few other things.

With the entire libhdf5 already covered by the bindings and just a few things missing (notably, 1.12), I don't see what exactly we're potentially winning here by using bindgen. It's definitely not applicable in any kind of automated manner here either.

aldanor commented 4 years ago

Closing in favor of #94, we will add 1.12 support fairly soon.

swfsql commented 4 years ago

Yes, it's really not direct to make those bindings, unfortunately.
eg. also the function-like macros are completely ignored by bindgen (even though they could resolve this is the coming months).

I don't see what exactly we're potentially winning here by using bindgen

It's not really a lot of advantages, but it would be easy to spot differences between versions, since it would be more deterministic from the headers; some comments could also be forwarded as #[doc] attrs if using certain clang args - not that there would be too many comments, nor that they are "properly" structured (as in rust).
So yeah, it really does not compensate for such change after all..

That being said, it's quite hard to make those, thanks for the work you have done there! (not even saying about the other functionality besides the binding).

I'm convinced that this should be closed as well, so I'll be closing it; thanks!