To avoid confusion and spurious newlines in the output.
Found by searching for a backslash followed by a newline, some
indentation, and then the end of multi-line string marker, using the
following extended regex:
```regex
\\\n +'';
```
The Swift wrapper uses a hook directly from cc-wrapper to set the
`-target` flag appropriately. This works because Clang and Swift use the
same syntax for `-target`, but there was never a guarantee that this
compatibility would be true for every option set in the hook. Indeed,
commit 369cc5c66b (PR #445119) made
availability warnings into errors by setting the
`-Werror=unguarded-availability` flag in this hook, which Swift doesn't
accept at the top level. This caused all invocations of Swift to fail
with the error `unknown argument: '-Werror=unguarded-availability'` -
including the bootstrap Swift, which meant that `swiftPackages.swift`
would fail.
This commit adds all `-Werror` flags to the list of flags that need to
be prefixed with `-Xcc`. I could have just dropped the flag, since Swift
already makes this an error, but you can have C/C++ targets in Swift
packages and we'd want to pass this flag on to them. (I'm not sure
whether the clang used for those targets is already wrapped, but if it
is there is no harm done.)
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.
Swift now works fine with standard environments using GCC or other
versions of LLVM. Some packages, like components of Swift itself or
others that combine Swift with features like C++ modules or C blocks,
may still need to use an LLVM‐based standard environment, but we
do not need to enforce a uniform `swiftPackages.stdenv` any more.
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.
