Use gcc 9 for CUDA 11

[leofang]

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.

Close #1000.

[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.

[leofang]

Not sure if this achieves what I think...

[isuruf]

Have you tried a rerendering of a feedstock with this? Copy this into cupy-feedstock, remove the timestamp and rerender. You'll find that it wouldn't work.

[leofang]

Thanks, @isuruf. I was following @h-vetinari's suggestion (#1000 (comment)). So what's the proper way to achieve the desired effect? I suppose you're saying zipping either in the global pinning (#1051 (comment)) or in the migrator (as done here) just wouldn't work, so I am lost...

[isuruf]

I'll let you know if I find one. 😄

[h-vetinari]

So, there's a bunch of problems here I think:

• updating the zip_keys in the pinning feedstock while a migrator that's updating some of the keys is in progress will probably break it (but then, I have close to zero experience with migrators)
• the more keys in a zip, the more fragile it becomes, because all the keys need to match in length under all circumstances (i.e. arches / OSes / etc.)
• cxx_compiler_version needs to be in there as well
• Doesn't look like everything will always have the same length (does the CI here check this)?

I think that it should be feasible after the migrator has run through to expand the zip_keys in the pinning feedstock... WDYT, @isuruf?

[kkraus14]

My understanding is that expanding cxx_compiler_version will also affect non-CUDA feedstocks in that they'll build for each version in which the selector matches.

[beckermr]

@isuruf Does the way we handle keys zipped with docker_image in the latest smithy help here?

[isuruf]

@isuruf Does the way we handle keys zipped with docker_image in the latest smithy help here?

Nope

[h-vetinari]

So #1222 / #1223 should make a dent here, but unfortunately still won't allow us to universally go to gcc 9+, because 10.2 is only compatible with gcc 8, see here.

[jakirkham]

What if we added cxx_compiler_version and fortan_compiler_version to the zip_keys?

[isuruf]

@jakirkham, please read @kkraus14's comment above

[jakirkham]

Right we can include one for the cuda_compiler_version with None

[isuruf]

I don't know whether you understood @kkraus14's comment or not. So, I'll say it again. Expanding cxx_compiler_version will produce matrix of builds for non-CUDA feedstocks which we do not want.

[jakirkham]

I don't think that is necessarily the case.

[isuruf]

Well, I've tried it multiple times before and I can tell you that it will be. Have you tried even once?

[leofang]

I think this PR is moot now that we have a proper mechanism to zip the C/C++ compiler version with the nvcc version 🙂