cloudhan

@vdittmer I think once I can confirm there is a non-breaking path toward multi-version deliverable toolchain, then I can proceed to marge those PRs.

Seem using a selected alias in `@local_cuda` can solve the problem. ```starlark config_setting(name="version") constraint_setting(...) constraint_value(...) # version1 constraint_value(...) # version1 alias(name="cublas", actual =select({ ":": "@local_cuda_cublas_v12.2.y", "//conditions:default": "@local_cuda_cublas_v12.8.x", })) ``` should...

I think > gather all the files is the only reasonable way to go. We don't want to be coupled with their abstraction. https://github.com/bazel-contrib/rules_cuda/blob/27d7499993bb64e92f44b13a642b6c1def00fa03/cuda/private/repositories.bzl#L89-L94 nvcc, cccl, and cudart are all...

@jsharpe I'd like move on to 0.3.x, and merge the first two changes with minor fix for `endswith("~")`. I think I can just drop the check as we don't rely...

All features are in the main tip, just not ready for a release, basically due to clang and lacking of `redist_json` equivalent for module based project.

Those `detect_*` are for locally install CTK/tools. Clang cuda toolchain is not address in these PRs at the moment.

@udaya2899 The idea then is not to **detect** but to **configure**, maybe manually. Because it seems that we don't have a way to query all configured toolchains and select the...

Or maybe just extend https://github.com/bazel-contrib/rules_cuda/blob/6a6d2f1d75b209c48d53051610418e47dc73f7e9/cuda/private/repositories.bzl#L196 with `CUDA_CLANG_LABEL` or `CUDA_CLANG_LABELS`. With the first label for compile executable and remaining for compiler_deps.

My apology, it is attr `compiler_files` https://github.com/bazel-contrib/rules_cuda/blob/6a6d2f1d75b209c48d53051610418e47dc73f7e9/cuda/private/templates/BUILD.local_toolchain_nvcc#L31 and https://github.com/bazel-contrib/rules_cuda/blob/6a6d2f1d75b209c48d53051610418e47dc73f7e9/cuda/private/templates/BUILD.local_toolchain_clang#L29 And is used in https://github.com/bazel-contrib/rules_cuda/blob/6a6d2f1d75b209c48d53051610418e47dc73f7e9/cuda/private/toolchain.bzl#L28-L31 I am not quite sure if we need to add some additional clang deps here.

https://github.com/bazel-contrib/rules_cuda/issues/283#issuecomment-2674336618 > error: cannot specify -o when generating multiple output files rules_cuda currently relies on the `-o` to make output name being reliable. We generally have 4 set of outputs:...