Solution to issue cannot be found in the documentation.
[X] I checked the documentation.
Issue
Packages that optionally use cuda compilers and specify c_stdlib_version: 2.17 # [linux] in conda_build_config.yaml are still getting builds for cuda_compiler=None, c_stdlib_version=2.12. I'm guessing this relates to the complex zip_keys for cuda and c_stdlib_version not handling conda_build_config at highest priority. I'm not 100% certain it's cuda related, but I've seen it twice (openmpi and lammps), both of which use the cuda compilers and have no-cuda variants which still want to use 2.17.
This can be worked around in this specific case by specifying os_version: cos7 in conda-forge.yml, but presumably something is wrong in the rendering.
Solution to issue cannot be found in the documentation.
Issue
Packages that optionally use cuda compilers and specify
c_stdlib_version: 2.17 # [linux]
inconda_build_config.yaml
are still getting builds forcuda_compiler=None, c_stdlib_version=2.12
. I'm guessing this relates to the complex zip_keys for cuda and c_stdlib_version not handling conda_build_config at highest priority. I'm not 100% certain it's cuda related, but I've seen it twice (openmpi and lammps), both of which use the cuda compilers and have no-cuda variants which still want to use 2.17.This can be worked around in this specific case by specifying os_version: cos7 in conda-forge.yml, but presumably something is wrong in the rendering.
example: https://github.com/conda-forge/lammps-feedstock/pull/198 which migrates from
sysroot_linux-64 2.17
toc_stdlib_version
pinning, which has no effect.Installed packages
Environment info