Use GCC 13 in CUDA 12 conda builds. #1773
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
/ok to test |
|
/ok to test |
| - cuda-nvcc # [not os.environ.get("RAPIDS_CUDA_VERSION", "").startswith("11")] | ||
| - nvcc # [os.environ.get("RAPIDS_CUDA_VERSION", "").startswith("11")] |
There was a problem hiding this comment.
This change is optional -- we could leave it as cuda11_compiler / cuda_compiler and not make the corresponding change in meta.yaml (leave {{ compiler('cuda11') }} in place).
The plus side of doing this is that it slightly simplifies the ignore_run_exports_from logic so it's no longer conditional on major versions.
There was a problem hiding this comment.
I like this change, keeping more of the future compiler-version churn concentrated in the git blame in conda_build_config.yaml.
There was a problem hiding this comment.
This approach looks good to me.
But I also support the idea you mentioned offline, of starting from the leaves of the RAPIDS dependency tree (e.g. cugraph) and working backwards... so not actually merging this rmm PR until everything downstream (within RAPIDS) has updated. I'm intentionally just leaving a "comment" instead of "approve" review for that reason... @ me any time we're ready to really merge this.
On that same subject... I think we'll also need changes for the compiler pins in dependencies.yaml, used for local development (including with devcontainers). I put up rapidsai/build-planning#129 (comment) with some thoughts on that.
bdice
changed the title
Description
conda-forge is using GCC 13 for CUDA 12 builds. This PR updates CUDA 12 conda builds to use GCC 13, for alignment.
These PRs should be merged in a specific order, see rapidsai/build-planning#129 for details.