Tracking: New Darwin SDK pattern migration

[getchoo]

Issue description

As introduced in #346043 and explained fully in https://discourse.nixos.org/t/the-darwin-sdks-have-been-updated/55295, nixpkgs has a new way of handling the Darwin SDK.

As a TL;DR:

• Instead of providing separate SDK frameworks and libraries, they are bundled together in an SDK that can be used with xcrun and the xcbuild package.
• The SDK includes everything you need to build applications. It also propagates certain packages automatically (libiconv, libresolv, and libsbuf). It is no longer necessary to include these conditionally on Darwin.
• The stdenv provides a default SDK (the unversioned apple-sdk package). A different SDK can be used to change the SDK in use by adding it to your buildInputs (see the stdenv documentation for more details).

Some examples of the migration are:

• Removing the following from packages when using the default (unversioned) SDK, as it is now in the Darwin stdenv

{
  buildInputs = lib.optionals stdenv.hostPlatform.isDarwin [
    darwin.apple_sdk.frameworks.Security
  ];
}

• Moving versioned SDK frameworks and libraries to the apple-sdk_${version} pattern

{
  buildInputs = lib.optionals stdenv.hostPlatform.isDarwin [
    darwin.apple_sdk_11_0.frameworks.Security
  ];
}

{
  buildInputs = lib.optional stdenv.hostPlatform.isDarwin apple-sdk_11;
}

• Removing usages of overrideSDK and darwin.apple_sdk_11_0.callPackage

Steps to reproduce

You can grep for usages of the SDK and it's components tree-wide:

For example, to find files using it in pkgs/by-name:

$ grep -Rl 'darwin.apple_sdk' pkgs/by-name

You may also want to search for specific components, i.e.:

$ grep -Rl 'Security' pkgs/tools/audio

Technical details

Some caution should be taken during the migration:

• The new pattern may cause build issues It will actually fix some issues! See Tracking: New Darwin SDK pattern migration #354146 (comment)
• It will cause rebuilds for Darwin
  • This means the migration should be limited to "leaf" packages (packages without packages that depend on it), or changes that will already cause rebuilds like updating
• Breaking changes must be accounted for

[getchoo]

Some recent PRs that made good progress on this:

• pkgs/by-name/[ab].+: migrate to new apple sdk #354097
• treewide: update own packages to the new apple-sdk pattern #352719
• treewide: cleanup own packages to utilize the new apple-sdk #352699

[emilazy]

cc @NixOS/darwin-maintainers

[emilazy]

Should probably mention that you also want to get rid of overrideSDK and darwin.apple_sdk_11_0.callPackage.

Also, re:

• The new pattern may cause build issues

These issues will already be present. The new scheme is all that exists; the old stuff is just mostly‐inert shims. Doing the migration won’t break any package that wasn’t already broken (and will fix packages that were broken).

[isabelroses]

@getchoo re:

{
  buildInputs = lib.optional stdenv.hostPlatform.isDarwin apple-sdk_11;
}

It was mentioned in #353439 that is "no longer recommended to propagate an SDK in most circumstances."

Also very small typo you forgot the . between hostPlatform.isDarwin, also lowercase i for the isDarwin.

[emilazy]

buildInputs doesn’t propagate anything.