cloudhan

I'm curious if it is possible to let bazel to use two differently configured toolchains for the same rule (different targets) in a single `bazel build ...`? If it is...

It seems some other rules do not support hermetic linux sandbox, maybe use [--strategy](https://bazel.build/reference/command-line-reference#flag--strategy) or [--strategy_regexp](https://bazel.build/reference/command-line-reference#flag--strategy_regexp) to override the default behavior for that rule's action? Or better, fix that rule....

Maybe a search path issue? For me, I need to use `dir bazel-rules_cuda` for symbol to work 

Can you provide a repro? I might dig into it once I have time.

@jsharpe I am not quite remember why it was designed as previous. What is the concern to disallow non-root module to call `local_toolchain`? I'd like to verify it a little...

It is not about cublas only, but rules instead. if you think abount it a bit further, say `cukernels` target is wrapped in a `clibrary` target and then is exposed...

Yeah, if we are going to implement it, we should align it with cc_* rules. For now, you can wrap you cuh headers with a cc_library first to achieve the...

See https://github.com/bazel-contrib/rules_cuda/pull/38#issuecomment-1303892768. Won't fix if you want to upgrade the bundled version to newer version. In that case, you need to roll out your own `thrust` target with repository rule.

You can refer to https://github.com/bazel-contrib/rules_cuda/blob/cf17ea98fc73314d18cd051a848e7c9df0a97325/third_party/thrust.BUILD as an example, without forking this repo.

The `CHAR_MIN` issue seems to come from missing climits header. https://en.cppreference.com/w/cpp/types/climits