Hi Rust community,
I've just published a crate that I would love your feedback and advice about: cl3.
The goal is to provide a simple, functional Rust interface to the OpenCL C API.
Any and all comments and advice will be gratefully received!
Thanks in advance,
Ken
It is a common convention in Rust that FFI bindings should be developed as two crates.
One crate is a pure translation of the C ABI into Rust, potentially using a tool like bindgen, and usually with a name ending in -sys. This is what libtls-sys and winapi are.
Another crate does the job of making a safe API for it. This is what libtls and wio do.
This is so that, if a single project winds up using two different safe wrappers at once, both can pull in a common “sys crate” binding, which will be responsible for finding the system libraries. Otherwise, a single Rust app could wind up linking to two different OpenCL libraries at one, and fail to link at the end.
https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages gives more info about this.
Basically, the build.rs and ffi modules become cl3-sys, and cl3 should depend on it.
Thank you Michael, that is an excellent point.
I shall consider dividing cl3 into cl3-sys, and cl3 as you propose.
However, there are already several opencl FFI binding sys crates in crates.io, so I'll investigate whether to base cl3 on one of those, before creating yet another opencl sys crate!
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.