darwin refactor: attempt at stacked PR #347814
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
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.
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.
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.
Add a new update script that locks the source releases to the indicated macOS version per the version pins in following repo: https://github.com/apple-oss-distributions/distribution-macOS
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 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.
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.
… set It is unusual to invoke a wrapped compiler without setting `DEVELOPER_DIR`, but it can happen when a user adds a compiler to their installed packages or when a package intentionally invokes the compiler without an environment (such as the GHC binary packages).
Without this change, all Darwin platforms mangle to the same suffix salt. That is normally not an issue because build = host should mean a non-cross build, but it causes issues on Darwin with static builds because `DEVELOPER_DIR_FOR_BUILD` and `DEVELOPER_DIR` will refer to different SDKs but mangle to the same `DEVELOPER_DIR` with suffix salt. The fix is to mangle static builds differently from non-static ones on Darwin, which allows building for a static Darwin target on a same-architecture Darwin host. This fix is applied only to Dariwn because the issue does not appear to affect other platforms.
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.
gnutar’s `configure` detects libiconv but fails to link it on Darwin.
Using the bootstrap stdenv avoids an infinite recursion from xcbuild depending on libpng depending on xcrun from xcbuild, which is propagated by the non-bootstrap stdenv.
file_cmds 352.40.6 added a C-based implementation of xattr, which is the version of xattr used on recent releases of macOS. Align nixpkgs with what macOS is shipping, which has also the benefit of allowing xattr to be cross-compiled (previously precluded due to Python limitations).
|
(It didn’t work. Oh well.) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an attempt at using GitHub’s limited stacked PR support to update all the follow up PRs to target staging from the darwin-sdk-refactor branch once #346043 is merged.
@emilazy