New jinja-function for handling sysroot

[h-vetinari]

Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

In the context of conda-forge/conda-forge.github.io#1844, we discovered that we have very few ways to encode the sysroot expectations for a given package, and that both on linux and on osx, a lot of conda-forge's infrastructure implicitly assumes cos6 and macos 10.9, because they haven't been changed for such a long time.

In the discussion of how to encode such constraints correctly (e.g. moving to >=10.13), the option of adding an osx-equivalent to https://github.com/conda-forge/linux-sysroot-feedstock came up, and that essentially, the only way to do this cleanly would be for recipes to explicitly note their dependence on the sysroot, and control the version via (the global) conda_build_config.yaml.

This would also solve priorisation issues with the current centos 7 sysroot, that needs to be weighed down (despite the higher version), since we still want to build for centos 6 by default (for now at least; the same problem appears for introducing the 2.28 sysroot).

One idea that would work already today would be to abuse the compiler() jinja-function, which would already allow to populate something like:

sysroot_{{ cross_target_platform }} {{ version }}

However, while {{ compiler('sysroot') }} might be acceptable in meta.yaml, this would look a bit awkward in the CBC

sysroot_compiler:          # [unix]
  - sysroot                # [unix]
sysroot_compiler_version:  # [unix]
  - 2.12                   # [linux]
  - 10.9                   # [osx]

original suggestion (obsolete)

Thus the idea came up to introduce a new jinja-function sysroot(...), which could work as follows:

# in meta.yaml
- {{ sysroot('default') }}`  # [unix]

# in cbc.yaml
sysroot_name:                # [unix]
  - sysroot                  # [unix]
sysroot_version:             # [unix]
  - 2.12                     # [linux]
  - 10.9                     # [osx]

The idea to make it take 'default' as an argument is threefold:

• make it clearer (than {{ sysroot() }}) that this is calling a function
• keep the door open to potentially distinguish different sysroots (e.g. alma vs. debian) in the future
• ensure that the default case does not need separate - {{ sysroot(...) }} per platform

Thus the idea came up to introduce a new jinja-function stdlibc("c"), that works like compiler("c")

# in meta.yaml
- {{ stdlib("c") }}`  # [unix]

# in cbc.yaml
c_stdlib:
  - sysroot                     # [linux]
  - macosx_deployment_target    # [osx]
c_stdlib_version:
  - 2.12                        # [linux]
  - 10.13                       # [osx and x86_64]
  - 11.0                        # [osx and arm64]

i.e. on linux-64, stdlibc("c") would expand to {{ c_stdlib }}_{{ cross_target_platform }} {{ c_stdlib_version }}

This would have several advantages:

• it's consistent signature with compiler() function (matching the fact that most compiled artefacts need a runtime lib)
• cbc arguments are consistent with <lang>_compiler{,_version}
• would have an obvious extension to cxx
• would be compatible with potentially building musl in the future (just add another c_stdlib implementation to CBC)
• should be extensible to windows (e.g. ucrt)

Why is this needed?

Solve various issues in conda-forge infrastructure, see above.

What should happen?

• decide whether stdlib function is a good idea
  • alternatives: reuse compiler function; other idea?
• design stdlib function
  • match compiler(<lang>) or diverge intentionally
• implement it

Additional Context

No response

[isuruf]

How about {{ stdlib('c') }}?

[h-vetinari]

I'd like that! It's clearer and more understandable than sysroot too, and it'd have an obvious extension to {{ stdlib('cxx') }}, in a way that's also consistent with {{ compiler(...) }}. Very nice

[h-vetinari]

It occurred to me today that we should be able to extend this to all platforms, and that if we go with {{ stdlib("c") }} and name the CBC variables in accordance with c_compiler{,_version}, then this would also fit in very nicely with supporting musl-builds, if we ever decide to do that.

c_stdlib:
  - sysroot                     # [linux]
  - sysroot_musl                # [linux]
  - macosx_deployment_target    # [osx]
  - ucrt                        # [win]
c_stdlib_version:
  - 2.17                        # [linux]
  - 1.2                         # [linux]
  - 10.13                       # [osx]
  - 10.0.22621.0                # [win]