ENH OSX sysroot/sdk package

[beckermr]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

TODO

• swap role of CONDA_BUILD_SYSROOT and SDKROOT
• only set conda-build items if in conda-build
• move items from clang compiler activation to here
• add sdk version 0 which uses the SDK on the system

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/osx-sysroot) and found some lint.

Here's what I've got...

For recipes/osx-sysroot:

• The home item is expected in the about section.
• The recipe must have some tests.

[beckermr]

here is a start @conda-forge/core

there is lots more to do here I think

it may make sense to have this package set the deployment target env instead of it appearing elsewhere in the CBC.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/osx-sysroot) and found some lint.

Here's what I've got...

For recipes/osx-sysroot:

• The top level meta key tests is unexpected
• The recipe must have some tests.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/osx-sysroot) and found some lint.

Here's what I've got...

For recipes/osx-sysroot:

• The top level meta keys are in an unexpected order. Expecting ['package', 'build', 'test', 'outputs', 'about', 'extra'].

[conda-forge-webservices]

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 (recipes/osx-sysroot) and found it was in an excellent condition.

[jakirkham]

Thanks Matt! 🙏

Added a couple suggestions. Though maybe these change if we go the zip_keys route (they may also need some tweaking anyway)

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/osx-sysroot) and found some lint.

Here's what I've got...

For recipes/osx-sysroot:

• The recipe must have some tests.
• The recipe must have a build/number section.
• The outputs section contained an unexpected subsection name. tests is not a valid subsection name.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/osx-sysroot) and found some lint.

Here's what I've got...

For recipes/osx-sysroot:

• The recipe must have a build/number section.

[conda-forge-webservices]

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 (recipes/osx-sysroot) and found it was in an excellent condition.

[jakirkham]

Thanks Matt! 🙏

This is coming along nicely 🙂

One other question to consider, do we want this to just be a metapackage or do we want it to contain things (like TAPI files or similar)?

IOW if a user tried to build a package using this recipe locally, what behavior should they expect?

[beckermr]

Yep @jakirkham. This is my thought exactly. :) I think this package should handle all of the SDK stuff we do in conda-build-ci-setup right now, TAPI, etc. Having it in build should behave just like the linux one.

[beckermr]

We'll want special hooks for cache downloads in ci across envs.

[jakirkham]

We should double check which things we can package both from a legal and technical standpoint. Recall issues on both fronts with the SDKs for example. Though TAPI might be ok (still should check though)

Some past discussion in PR: #5382

[jakirkham]

Should add am ok punting on that discussion for now. Just thinking about the questions users might ask when this package shows up and how we might respond to them. Similarly what we might like to add here in the future

[beckermr]

Oh I don't intend to package the sdk. Just put the scripts that download it in this package. It will be downloaded by the user when they run the job.

[beckermr]

OK let's see how this version works. Might fail on ci because CI uses 10.9 for SDK.

[h-vetinari]

Cool, I think this looks much more manageable. 👍

[beckermr]

Ok @h-vetinari this is ready for another look. I tested locally and squashed some dumb bugs. Works in zsh now too.

[h-vetinari]

Ok @h-vetinari this is ready for another look.

IMO this looks very nice, but I think some other (core) feedback would still be good, and especially if existing criticism can now be considered addressed and fixed.

[beckermr]

@conda-forge/core @isuruf any comments?

[beckermr]

Any other comments here @conda-forge/core?

[jakirkham]

Could you please share what the current intended usage would be in an example?

[beckermr]

Sure!

This package goes into build like this:

requirements:
  build:
    # expands to sysroot_{{ target_platform}} on linux
    # expands to macosx_deployement_target_{{ target_platform}} on osx
    - {{ stdlib('c') }}  
    - {{ compiler('c') }}

Our default pinnings will have

c_stdlib:
  - sysroot                   # [linux]
  - macosx_deployment_target  # [osx and x86_64]
  - macosx_deployment_target  # [osx and arm64]
c_stdlib_version:
  - 2.17                      # [linux]
  - 10.13                     # [osx and x86_64]
  - 11.0                      # [osx and arm64]

The stdlib jinja2 function doesn't yet exist in conda-build.

[beckermr]

Any other comments here @conda-forge/core?

[h-vetinari]

LGTM with or without the warning for mismatched SDK / deployment target.