Auto-generate CUDA bindings using Bindgen

[LutzCle]

This pull request addresses the issue that CUDA headers change between versions. Thus, over time, cuda-sys becomes incompatible with newer CUDA versions. See also #56.

For example, Nvidia introduced a breaking API change going from version 9.2 to 10.0. They added a new field "uuid" to the beginning of cuda_sys::cudart::cudaDeviceProp, making all the fields after "uuid" invalid memory locations.

We solve such compatibility issues by generating new bindings every time that cuda-sys is built. This ensures that we are source-compatible with the installed CUDA version.

[LutzCle]

The build failure in "build_example_add" occurs because circleci is pulling cuda-sys from crates.io. Those failures in accel are due to two naming inconsistencies as generated by bindgen, which are fixed in f94d399. If anyone has a better solution, please let me know.

[termoshtt]

We solve such compatibility issues by generating new bindings every time that cuda-sys is built. This ensures that we are source-compatible with the installed CUDA version.

I think generating bindgen will cause a header path issue. The path to cuda.h differs in each OS. For example, my ArchLinux environment does cuda.h is placed at /opt/cuda/include/cuda.h, and your bindgen cannot find it without CPATH=/opt/cuda/include environment variable.

[LutzCle]

That is correct. So far, I've come across two locations for CUDA installs:

• /opt/cuda on ArchLinux and
• /usr/local/cuda on Ubuntu.

One possibility to solve this would be to set the CPATH inside build.rs for these and other paths used by the large Linux distributions.

Are you aware of any good/clean solution? How do other CUDA-based projects solve this problem?

[termoshtt]

Are you aware of any good/clean solution?

I am also seeking a good way...

I think a combination of the default path (/usr/local/cuda and /opt/cuda) and user specified path (CUDA_LIBRARY_PATH) will be work better like I do in rust-cuda/cuda-sys@8b7a2ae
We have another option like llvm-sys, which supports several LLVM versions using crate's major/minor versions.

---

FYI, rust-cuda team has been started, and cuda-sys is planed to be moved to their organization based on the initial roadmap

https://github.com/rust-cuda/cuda-sys

This PR is also ported into rust-cuda/cuda-sys#4. I intend to release cuda-sys 0.3.0 including this PR from rust-cuda/cuda-sys, and then accel switch to it.

[LutzCle]

Great, I'm happy that cuda-sys will work on recent CUDA versions again!

I'm aware of the LLVM solution. However, it seems to trade-off ease-of-maintenance for ease-of-use. That is a good solution for larger projects, but might not be feasible (yet?) for cuda-sys.

Thank you for the pointer to rust-cuda. I've also been adding bits and pieces to accel, I will look into making another pull-request when I feel that something is mature enough to be of value. Essentially, I'm performing benchmarks and need the ability to launch C/C++ kernels and measure time.