f61e189ad3
This is effectively a rewrite of `overrideSDK`. It was required because `wrapGAppsHook` propagates `depsTargetTarget` with the expectation that it will effectively be `buildInputs` when the hook is itself used as a `nativeBuildInput`. This propagates Gtk, which itself propagates the default Dariwn SDK, making it effectively impossible to override the SDK when a package depends on Gtk and uses `wrapGAppsHook`. This rewrite implements the following improvements: * Cross-compilation should be supported correctly (untested); * Supports public and private frameworks; * Supports SDK `libs`; * Remaps instead of replacing extra (native) build inputs in the stdenv; * Updates any Darwin framework references in `nix-support`; and * It updates `xcodebuild` regardless of which input its in. The implementation avoids recursion for performance reasons. Instead, it enumerates transitive dependencies and walks the list from the leaf packages backwards to the parent packages. |
||
---|---|---|
.. | ||
bootstrap-files | ||
default.nix | ||
make-bootstrap-tools.nix | ||
override-sdk.nix | ||
portable-libsystem.sh | ||
README.md |
Darwin stdenv design goals
There are two more goals worth calling out explicitly:
- The standard environment should build successfully with sandboxing enabled on Darwin. It is
fine if a package requires a
sandboxProfile
to build, but it should not be necessary to disable the sandbox to build the stdenv successfully; and - The output should depend weakly on the bootstrap tools. Historically, Darwin required updating
the bootstrap tools prior to updating the version of LLVM used in the standard environment.
By not depending on a specific version, the LLVM used on Darwin can be updated simply by
bumping the definition of llvmPackages in
all-packages.nix
.
Updating the stdenv
There are effectively two steps when updating the standard environment:
- Update the definition of llvmPackages in
all-packages.nix
for Darwin to match the value of llvmPackages.latest inall-packages.nix
. Timing-wise, this done currently using the spring release of LLVM and once llvmPackages.latest has been updated to match. If the LLVM project has announced a release schedule of patch updates, wait until those are in nixpkgs. Otherwise, the LLVM updates will have to go through staging instead of being merged into master; and - Fix the resulting breakage. Most things break due to additional warnings being turned into errors or additional strictness applied by LLVM. Fixes may come in the form of disabling those new warnings or by fixing the actual source (e.g., with a patch or update upstream). If the fix is trivial (e.g., adding a missing int to an implicit declaration), it is better to fix the problem instead of silencing the warning.