[jefftime]

I use C a lot on my personal projects, and I have enjoyed learning Rust and playing with it to potentially replace my use of C. For the most part Rust has everything I want, but interfacing with C libs and headers can be so unergonomic. I wish there was a good alternative to bindgen that didn't shoot your build times up. Offline binding generation works, but then you have to manually deal with versioning. I don't really know what the solution is, but it's currently one of the pain points I have with Rust

[JoshTriplett]

That's one of the items on the list to get better C parity. Binding to C libraries should work as easily as C's #include.

[Tuna-Fish]

Wouldn't the simplest solution be to just make bindgen emit "from <file name>@<hash>" into the /* automatically generated by rust-bindgen */ comment?

Then when it loads a .h, hash it, and if the hash is unchanged don't write anything. This way, the cargo/rust incremental compilation does the rest of the work. Minimal change to how it works now, yet the compile times go way down.

If you are willing to live dangerously, you could always use modification times instead of hashes to avoid having to even read the .h files on compile, but frankly that sounds like it'd just make enough heisenbugs that people would start doing clean compiles just in case.

[JoshTriplett]

Caching would certainly help improve the performance of bindgen. But I'd also like to improve the quality of the bindings, avoid the need for a build script to invoke bindgen, and reduce the amount of boilerplate needed to make safe wrappers.

[okl]

Can't you call bindgen from a build management tool that checks if the source file has changed? Or do you mean building in a CI setup?

[jefftime]

That's a good point! This might be a good way to go about it