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

If you can guide me with a high-level overview, I can send a PR to use llvm_toolchain's clang. So, right now, the only way is to use nvcc or system non-hermetic clang?

@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 clang one as host+device compiler.

The current detected clang use compiler_executable attr with a path as its value. See

You can actually configure it to use the newly added compiler_label with the hermetic clang executable as its value. But you also need to fiddle with the compiler_deps. Definitely doable, but not sure if there is a sane way for the user :(

Yes, an optional arg, maybe passed to cuda.toolkit called "clang_compiler_label" propagated till the clang declaration, maybe?

I can consider sending a PR for that.

Will this label be explicitly only for clang? Because otherwise we have to propagate the same for nvcc which I'm not sure if we want to do.

Or maybe just extend

Can you help me with understanding compiler_deps? They are set in BUILD.nvcc only and are used by both nvcc and clang or am I getting it wrong?

My apology, it is attr compiler_files

And is used in

I am not quite sure if we need to add some additional clang deps here.

You can actually configure it to use the newly added compiler_label with the hermetic clang executable as its value.

This comment helped me. I added the following in my own configuration of cuda_toolchain:

cuda_toolchain(
    name = "clang-local",
    compiler_files = "@local_cuda//:compiler_deps",
    compiler_label = "@@toolchains_llvm++llvm+llvm_toolchain_llvm//:bin/clang++",
    toolchain_config = ":clang-local-config",
)

Although I had to re-declare the whole toolkit for this one line change, this makes the compiler to be the hermetic clang from llvm. That said, once I get my whole setup working (blocked by this error with --cuda-path), I can send a change to improve to use a label passed in as env or from the cuda.toolkit extension call.

#283 (comment)

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: {basename}.o, {basename}.pic.o, {basename}.rdc.o and {basename}.pic.rdc.o where {basename} is parsed from srcs filename, they are all placed in <some_prefix>/_objs/. Also if your target have multiple files with same name, say srcs = ["a.cu", "nested/a.cu"], then they will be _objs/0/a[.pic][.rdc].o and _objs/1/a[.pic][.rdc].o. This behavior is the same as cc rules. So being able to control the output name and path is mandatory.

I am only compiling one file "foo.cu" which produces two '.o' files I assume. I believe this is specific to clang.

#283 (comment)

fatal error: 'curand_mtgp32_kernel.h' file not found

maybe just add the curand as an mandatory deps to the generated repo, to make the problem much easier to solve.

The downloaded repos don't have a version.txt or version.json file.

For version.json, we can just add it, the redistrib.json contains all the information.

clang++-19 -xcu -c --cuda-compile-host-device kernel.cu -o kernel.o produces only one file actually.

I'll retry on Monday with clang++-19. I had to downgrade to 18.x because the expectation was to be < 19.

@udaya2899 , I'm also interested in helping out. Do you have a branch/commit I can start looking at?

@lromor, I've been trying out locally. Which part of this issue are you also facing a similar problem?

@udaya2899 , I have toolchains_llvm and I want to tell rules_cuda to use that instead of relying on its own heuristics. Something similar to what you did, but I'm interested in adding a proper extensions that allows the user to configure that.

clang++-19 -xcu -c --cuda-compile-host-device kernel.cu -o kernel.o produces only one file actually.

This hint helped me. I was earlier using 'clang-cpp' from llvm, but now I use 'clang++' and it doesn't complain about the multiple output files anymore. Phew!

@lromor, that's what I'm trying to do. cuda_toolchain:

used an older way of toolchain resolution which is deprecated. rules_cc mentions using a different find_cc_toolchain from @rules_cc:

https://github.com/bazelbuild/rules_cc/blob/07e3cb66d0d516d5d855c745a3a1b5bae0b67e5e/cc/find_cc_toolchain.bzl#L16C1-L53C4

I tried it but of not much success. For example, my toolchain is configured to use libc++ instead of libstdc++ and I can't get it to work.

Update:

# added to .bazelrc
build:cuda --@rules_cuda//cuda:copts='-stdlib=libc++'
build:cuda --@rules_cuda//cuda:copts="-D_ALLOW_UNSUPPORTED_LIBCPP" # had to explicitly set this for CUDA to be okay with an x86 system using libc++

With this, I'm able to build CUDA code using my own clang++ from toolchains_llvm along with libc++