Add thrust and cub repos

[jsharpe]

As thrust can also be used via an OpenMP backend, make this available as repository outside of the toolchain.

[jsharpe]

I may have missed some includes in thrust - the set here are just from what I've used on another project and so may be missing some for some functionality.
Have also got rules_license rules commented out here; its probably not quite stable enough yet to take a dependency on rules_license but when we do we'll want to add those back in.

[cloudhan]

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 are so many libraries and versions there, this should belong to a seperate repo that provides CUDA related libraries recipes, say cuDNN, TensorRT, etc.

[jsharpe]

I don't necessarily think it should be a separate repo but could be a separate workspace contained within this repo. Ultimately it'll become a bzlmod registry for all these libraries.

We can add version selection to this quite easily as an argument to the dependencies macro. The motivation for adding this is two-fold; to allow use of the downloadable tarballs for the cuda toolchain and to allow use of thrust / cub in the case that the user has disabled the cuda toolchain. Its perfectly valid to use thrust with an openmp backend and so this allows the user to do this without needing a cuda install to actually be present.

[cloudhan]

They are not mandatory, please move them into third_party/ also. Otherwise, our core rules depends on not in use remote files. Lets keep them minimal.

[cloudhan]

Any reason to make the glob so detailed? This prone to be affected by upstream implemtation details change. Why not just glob([cub/**/*.cuh]).

[cloudhan]

This line is redundent.

[cloudhan]

Maybe call them include-hdrs.

[cloudhan]

Same

[ryanleary]

Wanted to point out that cub, thrust, and libcudacxx have all been coalesced into https://github.com/NVIDIA/cccl (all three projects remain header-only) recently, so if this integration moves forward, it should use that repository.

Would it make more sense to add build rules to cccl directly? I can reach out to that team - though it may be somewhat onerous to reach full coverage of the various flags/preprocessor directives

[cloudhan]

The current blocker is merely how do we avoid <dir_of_local_cuda>/cuda/include/{cub,thrust} been exposed to the :cuda_headers,

rules_cuda/cuda/runtime/BUILD.local_cuda

Lines 26 to 30 in 7a29239

	cc_library(
	name = "cuda_headers",
	hdrs = [":_cuda_header_files"],
	includes = ["cuda/include"],
	)

Or more generally, we need a confugrable way to piece together different packages (like in <dir_of_local_cub> and <dir_of_local_nvcc>, etc) to form a unified cuda toolkit directory, and use it as the <dir_of_local_cuda>/cuda. This will be useful for #72 as well

[jsharpe]

I think ultimately this will be replaced by bzlmod modules: bazelbuild/bazel-central-registry#1058.
@ryanleary ultimately yes if the CCCL team can own releasing this to the BCR with build rules then that would be the best solution for the community.

[cloudhan]

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