Most Darwin source releases vendor private headers in a separate
derivation and add them to `NIX_CFLAGS_COMPILE` (to avoid propagating
them in static builds). Adopt this pattern for consistency with the
other source releases.
The SDK library path is normally add by the ld wrapper, but ld64 is
being used unwrapped in this check phase. Ensure it can find the
requires SDK stubs by passing them via the clang wrapper.
Many packages need only libtool from cctools, which is different from
GNU libtool (commonly used with other autotools), so it can’t be
provided by default with the Darwin bintools. Providing it as a separate
output allows packages to use cctools’s libtool without pulling other
tools they may not want.
macOS ships with several stubs in `/usr/bin` that invoke `xcrun` to run
the tools from the active SDK. When `/usr/bin` is in `PATH`, this will
cause `xcrun` from xcbuild to invoke itself over and over. Filtering
`/usr/bin` from `xcrun`’s search path prevents this from happening.
xcbuild determines the SDK dynamically, so overriding the `sdkVer` no
longer works. If packages want to change the SDK, they need to add one
of the SDK packages to their inputs.
Take advantage of the new Darwin SDKs to dynamically determine SDK
information such as path, version, and binaries (via `xcrun --find`).
This is accomplished by relying on the existance of `DEVELOPER_DIR`,
which the SDK will set up in nixpkgs.
With this workaround enabled, CMake looks for SDK headers and libraries
in `${SDKROOT}/var/empty`, which ensures it will not find them.
Disabling the workaround in just this case allows CMake’s SDK support to
work with the SDKs in nixpkgs while still not including other, impure
paths in its search paths.
This is a new packaging of the Darwin SDK. Instead of splitting
libraries and frameworks into separate packages, it provides a single
package for the whole SDK.
# Features
- Vendored files are removed from the SDK. There are 50+ different
packages that are vendored by upstream (depending on the version);
- Components that are built in nixpkgs (either from upstream or from the
source releases) are also removed. If they need to be included by
default, they are propagated;
- A single SDK pattern is used to package all SDKs, and scripts are
provided to aid updating the SDK version and its source release
versions. This makes adding new SDKs much easier;
- SDK overrides are handled by adding the SDK version you require. If
multiple SDKs are present, only the newest is used. It is possible to
have different SDKs for each of build, host, and target platforms;
- Private headers are no longer provided by default unless you use the
SDK’s `privateFrameworksHook` to add them. It does the right thing
when multiple SDKs are in your inputs;
- Source releases for the SDK version are available via a passthru
`sourceRelease` function. This is mostly useful for getting private
headers for building source releases in the darwin attrset; and
- The same versions of propagated components are used on both platforms
(e.g., the same libresult, libiconv, etc).
See `pkgs/by-name/ap/apple-sdk/README.md` for details on how the SDK
derivation is structured and how to update it.
