Build CUDA 10.2 Support

conda-forge / cupy-feedstock

A conda-smithy repository for cupy.

BSD 3-Clause "New" or "Revised" License

5 stars 23 forks source link

Build CUDA 10.2 Support #25

Closed jakirkham closed 4 years ago

jakirkham commented 4 years ago

Partially addresses issue ( https://github.com/conda-forge/cupy-feedstock/issues/15 ).

Checklist

[x] Used a 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)
[x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

conda-forge-linter commented 4 years ago

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.

jakirkham commented 4 years ago

I think we need to bump the global cudnn pin to 7.6.5.

leofang commented 4 years ago

@jakirkham Thanks for working on this! I have a question: I've been following conda-forge/conda-forge-pinning-feedstock#360 but I still have no clue what's going on there. I don't understand: 1. what's a migration, and 2. what exactly prevents an auto-rendering from happening and requires a manual editing as you did here. Could you fill in the context for the rest of us when you have time please?

jakirkham commented 4 years ago

A migration is an automated rollout of PRs like this one following topological sort order (upstream packages first and then their dependents). Unfortunately there appears to still be a bit of work to get the automation around migration to work correctly for CUDA upgrades. In this case it seemed easier to simply make the migration PRs manually, which is what we do. The migration is then followed by graduating that content into conda-forge-pinning.

Re-rendering is a different process which inspects conda-forge-pinning and the conda_build_config.yaml in the recipe here and use this to generate the contents of .ci_support. These contain Python versions, CUDA versions, and other relevant constraints. It also ensures that CI's contain one build per file in .ci_support. Other content like the README.md is also generated in this process.

Running an automated re-render would still work here. It was just easier to do it locally when making these changes.

Does that help? 🙂

leofang commented 4 years ago

Does that help? 🙂

Definitely! 👍 Thanks.

leofang commented 4 years ago

@jakirkham shouldn't we bump the build number?

jakirkham commented 4 years ago

@jakirkham shouldn't we bump the build number?

Normally adding a new matrix element would not have a build number bump. However as we are bumping the version of cudnn we do need one. Thanks for catching that. Have pushed a build number bump here and to the v6 PR. Please let me know if there is anything else.

jakirkham commented 4 years ago

Thanks for the review and help @leofang! 😄