These replacements didn't apply cleanly to Swift 5.8 anyway, we just
didn't notice. They don't appear to cause any problems and regardless,
the goal is "no more broken than before"
This regularly broke things – as can be seen from the number
of packages that were opting out of it – while providing only a
dubious and partial benefit to purity that other build systems did
not “enjoy”.
It has become associated with Darwin, but was actually introduced
in 2007 as part of 67d41efde1,
a work‐in‐progress commit for KDE 4 that introduced the CMake
setup hook. It has haunted us ever since, and will presumably become
even better at doing so now that it is a dead ghost.
Of course, it is possible and even likely that more impure paths will
leak into Darwin builds from third‐party CMake modules included
in packages. However, considering it already disregarded many of the
most common macOS system paths, it will be better overall to address
these in a targeted manner than dealing with the effects of this
brute‐force hook. In the long run, a good sandbox is going to be
the solution for reliable build reproducibility on the platform.
libc++ only supports a limited range of Clang versions, so this was
relying on the LLVM version corresponding to the one used in Swift’s
fork. Since Swift builds its own LLVM 15 anyway, we can simply install
the required libc++ headers along with it.
Swift needs Clang to link with. The linker patch breaks linking
when using Swift with a GCC‐based standard environment.
Similarly, the internal Clang headers in the resource directory are
coupled to the corresponding version of Clang. The resource root patch
caused Swift’s Clang to use the resource directory from the version
of Clang used in the build environment, which is only compatible if
the versions match.
Instead, hard‐code the Clang path in the patches and wrappers.
Honestly I did this in the middle of trying things and then forgot
about it, and I just don’t feel like bootstrapping the whole thing
again to drop this commit.
https://hydra.nixos.org/build/299109156
Per the release notes: https://docs.python.org/3/whatsnew/3.13.html
> Remove the PyEval_ThreadsInitialized() function, deprecated in Python 3.9. Since Python 3.7, Py_Initialize() always creates the GIL: calling PyEval_InitThreads() does nothing and PyEval_ThreadsInitialized() always returns non-zero.
Dunno if this is correct, there's other `hostPlatform.isDarwin`
conditionals which may be wrong.
Leaving the other conditionals to swift maintainers or people who are
interested in swift cross-compilation
```
$ nix repl --file . --system aarch64-darwin
nix-repl> pkgsCross.aarch64-multiplatform.swift
«derivation /nix/store/kqbaqwdfc9g0yvkq4ffrlqspranprlmy-swift-wrapper-aarch64-unknown-linux-gnu-5.8.drv»
nix-repl> pkgsCross.aarch64-multiplatform.buildPackages.swift
error:
error: expected a string but found null: null
at /home/artturin/nixgits/my-nixpkgs/.worktree/2/pkgs/development/compilers/swift/compiler/default.nix:586:11:
585| #WATCHOS_SIMULATOR
586| }.${targetPlatform.darwinPlatform}}
| ^
587|
```
Fail to build with ninja 1.12 when NIX_BUILD_CORES is low (Hydra or Github Actions):
```
ld: warning: directory not found for option '-L/nix/store/g9rbp9m6vs1xj4jl6b6vjb6bm8kgr107-SDKs/MacOSX10.15.sdk/usr/lib/swift'
...
ld: warning: Could not find or use auto-linked library 'swiftCompatibility56'
Undefined symbols for architecture arm64:
"__swift_FORCE_LOAD_$_swiftCompatibility56", referenced from:
__swift_FORCE_LOAD_$_swiftCompatibility56_$_Optimizer in libswiftCompilerModules-bootstrapping1.a(Optimizer.o)
...
```
Can reproduce using `nix --option cores 2 build -f . swiftPackages.swift-unwrapped`.
Until we find out the exact cause, follow [swift upstream][1], pin ninja to version
1.11.1.
[1]: https://github.com/swiftlang/swift/pull/72989
Swift releases are associated with particular Darwin SDK versions. They
don’t _have_ to use that version, but it makes sense to use that version
by default. The deployment target is set to the supported Swift minimum
versions. Unlike C and C++, Swift requires you to availability
annotations, so propagating a newer SDK should be safe.
libarclite is needed to support ARC on very old deployment targets
(10.10 and older). None of these deployment targets are supported
deployment targets in nixpkgs, especially for Swift. This removes the
need to package the command-line tools executables.
Swift’s build makes a few assumptions about how the SDK is set up that
are not true anymore with the new SDK. Fix it to find the SDK at
`$SDKROOT` and copy additional stubs it needs to bootstrap.
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"
```
Since theey is not active in a long span of time.
None of the packages in this commit are orphan.
All the packages listed here are related to Swift programming language compiler
suite.
David McFarland