Some compilers may know to check these paths when `SDKROOT` is set, but
it’s not assumed they do. `SDKROOT` is instead derived from the
`DEVELOPER_DIR`, and `NIX_CFLAGS_COMPILE` is set up with the sysroot and
necessary framework and include 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.
libsbuf is required by some of the source release updates that will
be done. Unfortunately, it is only available on macOS 14 and newer, and
there is no source release available currently.
This is a port of libsbuf from FreeBSD, which appears to be the origin
of the header provided in the 14.x SDK. It provides the same ABI as the
system dylib and same API as the the SDK header while being available on
all supported deployment targets in nixpkgs.
Note: This package is not based on libsbuf from the FreeBSD package set
in nixpkgs because: it doesn’t build on Darwin, and using it would pull
many FreeBSD packages into the Darwin bootstrap, which is undesirable.
This is a replacement for the family of `appleDerivation` functions
currently used. It is patterned after the `mkDerivation` used in the BSD
package sets. It also provides additional support for using Meson to
build source releases.
This hook is used by source releases that build with Meson to assert
that the Xcode project has not changed since the previous release. This
is meant to be a check to force those updating source release packages
to make sure they have incorporated any changes that were made to the
Xcode project into the Meson build.
The new Darwin SDK pattern relies on an effectively empty, stub libc
implementation. The actual libSystem to be linked is located dynamically
based on the active SDK for the target. Independent build, host, and
target SDKs are all supported by Darwin.
The stub libSystem contains empty `include` and `lib` folders to avoid
warnings from wrappers that add those paths unconditionally, which can
turn into errors when a package is building with warnings-as-errors.
While it would be nice if a fallback libc could be provided, SDK headers
are not compatible between framework versions. Providing a fallback
risks mixing headers from different frameworks, which can result in hard
to diagnose errors involving semicolons or other punctuation.
Adding the hook allows the deployment target to be changed without
having to mess with the stdenv. The can also be propagated, which is
useful for libraries that have a minimum deployment target higher than
the default in nixpkgs. In that case, they can propagate the hook to
ensure library users are not targeting an unsupported version.
Packages propagated by the SDK need to use a stdenv that does not
propagate anything. Otherwise, an infinite recursion will result when
building those packages.
For consistency, all source releases should use the bootstrapStdenv.
This effectively disables the native GitHub codeowners feature
and enables the new alternate codeowners mechanism introduced in
https://github.com/NixOS/nixpkgs/pull/336261
This means that:
- We can now declare users without write access as code owners!
- Targeting the wrong branch won't trigger mass pings anymore!
This makes this codeowner mechanism behave differently than the native
one, but there's no other way to avoid rerequesting reviews from teams
when a member already reviewed the PR.
The automation should never rerequest reviews from users that already
reviewed the changes, which is what was happening before this change:
https://github.com/NixOS/nixpkgs/pull/347354#event-14570645380
Also reorder the arguments to make more sense