cloudhan

Not necessary production ready, but at least usable. It needs more users to test it out before I can say it is production ready. Because it is a build system,...

@Artem-B Do we have prebuilt llvm package with NVPTX backend enabled. I'd like adding a building CI. So that I can confidently close this issue finally.

llvm apt clang is also built with NVPTX enabled, we can use that too.

This is partially fixed by #143. Later I will add a full integration test by adding nccl as an example. The cloudhan/nccl-example branch should be buildable with both clang and...

@hypdeb Could you please try `--repo_env=CC=clang`? I am not sure how it goes if you mix gcc as cc compiler and clang as cuda compiler

Close with #158

The problem here is the library is freezed for a single version and cannot be upgraded/downgraded by the user easily. Might better to stick with cuda toolkit bundled version. There...

The current blocker is merely how do we avoid `/cuda/include/{cub,thrust}` been exposed to the `:cuda_headers`, https://github.com/bazel-contrib/rules_cuda/blob/7a29239f41bbe1662104eb1b4ccf7bcd846ce3de/cuda/runtime/BUILD.local_cuda#L26-L30 Or more generally, we need a confugrable way to piece together different packages (like...

@jsharpe We still need to exclude the folder under /include/{cub,thrust} to make it clean. Otherwise the deps order might cause incorrect include, similar to #105

This is quite reasonable usage, it just skip the stage1 compilation and only use the stage2 compilation. But this does not fit well into the [`actions.compile`](https://github.com/bazel-contrib/rules_cuda/blob/main/cuda/private/actions/compile.bzl) design. Becase it support...