In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Based on the derivation from xcbuild.sdk. apple_sdk.sdkRoot provides
version plists and a hook that passes them automatically to the compiler
as `-isysroot`. This is needed to correctly set the SDK version in
compiled binaries. Otherwise, clang will infer the SDK version to be the
same as the deployment target, which is usually not what you want.
The current hook specifies the path to the framework library, but
nixpkgs does not actually provide the library when linking against the
system framework. It provides a text-based stub (`.tbd`) instead. ld64
will find the stub and use it, but lld will not when the full path is
specified. Both linkers work if the extension is included, so do that
for compatibility with both. This fixes using lld with CoreFoundation
(e.g., to support LTO on Darwin).
This can result in swift-corefoundation being included even when a
derivation uses `apple_sdk_11_0.stdenv` directly, which may result in
hard to debug compiler errors (unless you just happen to know cryptic
compiler errors means the 10.12 and 11.0 SDKs have been mixed).
Contrarily to the other frameworks, System framework's TBD file
is a symlink pointing to `${MacOSX-SDK}/usr/lib/libSystem.B.tbd`.
This produces an error when using the framework, as:
1. The original file is not copied into the output directory
2. Even if it was copied, the relative path wouldn't match
Resulting in the symlink being broken and the linker failing when
trying to link `-framework System`.
The fix applied consists in replacing the symbolic link with the
actual file, as this is easier than fixing the link and doesn't
seem to produce any side effects.
The SDK was missing SDKSettings files. This is usually not a problem for
Nix builds, because we generate our own fake SDK structure when
necessary (in xcbuild), but not having these files blocks using the
upstream Apple SDK in tooling such as gen-frameworks.py.
This reverts commit 511f21df7c.
In apple_sdk_11_0, the xpc package contains only headers that are
already part of libsystem, so this change did nothing.
For Swift and `-fmodules`, this actually caused an error, because
there was now a duplicate module in the search path.
Some packages like `bazel-watcher` seems to have broken after
9dc3b14859
Where `xpc` was removed from `IOSurface` dependencies.
`CoreServices` were pulling `xpc` via `IOSurface` and so `Security`
didn't break. Now explicit dependency on `xpc` is needed to avoid
errors like
```
In file included from __main__/external/com_github_fsnotify_fsevents/go_1_10_after.go:6:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:23:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/IconsCore.h:23:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:29:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/CSIdentity.h:43:
In file included from /nix/store/dg51rm1bapffbqvn46bh43km4dhcsy9p-apple-framework-Security-11.0.0/Library/Frameworks/Security.framework/Headers/Security.h:87:
/nix/store/dg51rm1bapffbqvn46bh43km4dhcsy9p-apple-framework-Security-11.0.0/Library/Frameworks/Security.framework/Headers/SecCode.h:35:10: fatal error: 'xpc/xpc.h' file not found
^~~~~~~~~~~
```
Should help with https://github.com/NixOS/nixpkgs/pull/203519
Stdenv on aarch64-darwin pulls in (bootstrap-stage4) objc4, unlike
x86_64. However derivations that otherwise depend on objc4 would use a
a different objc4 derivation on top of the final stdenv.
Because this library defines an LLVM module, having multiple instances
of it in the import path will interfere with builds.
