restrict host compiler version based on CUDA version

[kkraus14]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Closes #51

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[kkraus14]

@conda-forge-admin, please rerender

[kkraus14]

Using run constraints felt more appropriate than run dependencies to continue to allow people to bring their own compiler

[jakirkham]

I don't think this will work as the version is already set in the recipe's build variants, which conflicts.

My guess is we will need to use zip_keys with the cxx_compiler_version in conda-forge-pinning like what we have done already with docker_image. Though we can test this hypothesis out by adding a conda_build_config.yaml to the recipe here with the same change.

[kkraus14]

I'm a bit lost as to how I would go about doing this. Would I create a new key with say [9, 7, 7, 7, 9] to match the cuda_compiler_version keys? How would I make {{ compiler("c") }} play nicely with that since it seems to already be set by the earlier zip key?

[h-vetinari]

I didn't manage to get that particular zip working: conda-forge/conda-forge-pinning-feedstock#1000

[kkraus14]

Closing as this approach won't work. Will open a PR in conda-forge-pinnings.

[jakirkham]

Sounds good.

Yeah to your earlier question, we would need to combine them into the same zip_keys group. Shouldn't be too difficult. We can also build a migrator on the same premise and test that out here as well ( #47 ). That should help us build confidence that it is doing the right thing.