Managing multiple cudatoolkit versions

[jakirkham]

It would be useful to have branches for the different versions being supported. That way if we need to backport changes from master to other versions of the cudatoolkit package, we can do that.

[jakirkham]

Alternatively we might consider a way of including multiple versions in master at one time. This might incur a bit more work to handle the different versions appropriately, but could be less work in terms of the git maneuvering required (and chance of missing backporting something important).

[leofang]

Thanks, John! Either solution is good to me.

[gmarkall]

FWIW, Numba's fork of the cudatoolkit recipe kept the recipes for different CUDA toolkit versions in folders within one branch: https://github.com/numba/conda-recipe-cudatoolkit

[jakirkham]

Another option to consider would be parametrizing the recipe a bit so it can handle building several versions at once using the same build scripts. This might make it easier to keep the different versions up-to-date without winding up with versions missing fixes or going stale. We do something similar with the nvcc wrapper recipe.

[jakirkham]

Do you have any thoughts on this @jjhelmus? 🙂

[jjhelmus]

I'm open to having branches or folder for each CUDA version or some other option. Branches match the layout used by conda-forge in their feedstocks.

[leofang]

When this happens, I would also like to see @gmarkall's #5 being backported to other CUDA versions. We need cudadevrt in all versions.

[leofang]

@jakirkham mentioned that when we do this, we should also backport the ppc64le support (#6) that was merged earlier today.

[jakirkham]

I'm wondering if we follow this approach if we can avoid backporting to other branches or having multiple directories. IOW allowing things like ppc64le to continue to just work on the same single recipe. It may be a little bit of work to keep everything in one recipe. However it should make sure we don't miss including fixes in all versions 🙂