Skip to content
This repository was archived by the owner on Mar 29, 2025. It is now read-only.

*-sys crate design #9

Closed
termoshtt opened this issue Jan 5, 2019 · 2 comments · Fixed by #19
Closed

*-sys crate design #9

termoshtt opened this issue Jan 5, 2019 · 2 comments · Fixed by #19

Comments

@termoshtt
Copy link
Member

termoshtt commented Jan 5, 2019

FFI crate separation, e.g. cuda-sys, cudart-sys, and cublas-sys has benefit

How to split?

  • cuda-sys
    • FFI for CUDA Driver API (libcuda.so)
  • cudart-sys
    • FFI for CUDA Runtime API (libcudart.so)
  • cublas-sys
    • FFI for cuBLAS

and so on. (edit: Drop cuFFT)

How to manage?

  • each *-sys crates are managed as a subdirectory in this repository
cuda-sys/cuda-sys/Cargo.toml
         cudart-sys/Cargo.toml
         cublas-sys/Cargo.toml
@LutzCle
Copy link
Contributor

LutzCle commented Jan 9, 2019

Would it make sense to reject #4 and open separate PRs for each submodule? Then we could at least get cuda-sys and cudart-sys merged quickly and follow up with the rest. As @kngwyu noted in #4, it's easy to miss some parts that then hold up the entire PR.

@termoshtt
Copy link
Member Author

Would it make sense to reject #4 and open separate PRs for each submodule?

Yes, I'm considering to split code generation part from #4 to enable static code generation at https://github.com/rust-cuda/cuda-sys/tree/code_generator branch (I'm going to create PR for it).
It replaces CUDA8-based binding to CUDA10-based binding which I generated on my env.

Once code generator is splitted, *-sys separation will be straight forward.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants