CUDA SDK packages & usage docs

[jakirkham]

At some point it would be good to refresh the existing CUDA docs, explain how the newer style CUDA SDK packages are implemented ( https://github.com/conda-forge/staged-recipes/issues/21382 ), and how best to use them in feedstocks ( https://github.com/conda-forge/staged-recipes/issues/21382 ). On that last point in particular it would be good to cover any migration steps we may need to perform. Opening this issue as a placeholder for this as well as a discussion location on what else we might want to include and how/where we want it included.

[pentschev]

From discussions in https://github.com/rapidsai/ucxx/pull/61 , it seems that cuda-nvcc is required even if linking only from the host compiler, @jakirkham wrote:

Essentially the CUDA compiler package is needed to configure the search paths correctly with CMake, Conda compilers, etc.. There's not a good way atm to handle the needs of these cases without that package as it requires things like adding nvcc.profile files (and patching them) as well as altering the flags the Conda compilers get, which basically only makes sense in the CUDA compiler package

This is not an obvious requirement for anyone who relies on CUDA driver/runtime API only for host-side builds (i.e., libraries that do not compile any CUDA kernels), so documenting that requirement properly would be helpful.

[h-vetinari]

The knowledge base section on this is by now pretty out of date - still talking about cudatoolkit and CUDA 10.1...

[jakirkham]

We did a fair bit or iteration internally and published documentation in the cuda-feedstock

However there is quite a bit of detail there and it is structured to provide information to different kinds of users (maintainers of the CUDA SDK packages, 3rd party recipe maintainers, consumers of packages, etc.). We are a little unclear what is helpful/useful, what gaps there are, and whether the divisions are appropriate (or need more restructuring)

Would appreciate if more folks could start reading those docs and sharing feedback on the cuda-feedstock in the form of new issues or new PRs

Once we have more confidence on the usefulness of those docs, we can figure out better integration