-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
swift: split build & Darwin support. #189977
Conversation
a6c8932
to
ec292a8
Compare
] ++ lib.optional stdenv.hostPlatform.isAarch32 ./armv7l.patch; | ||
|
||
../../common/compiler-rt/darwin-plistbuddy-workaround.patch | ||
./armv7l.patch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this patch now here unconditionally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See: #186575 (review)
@@ -59,8 +60,9 @@ stdenv.mkDerivation { | |||
# extra `/`. | |||
./normalize-var.patch | |||
../../common/compiler-rt/libsanitizer-no-cyclades-11.patch | |||
] ++ lib.optional stdenv.hostPlatform.isAarch32 ./armv7l.patch; | |||
|
|||
../../common/compiler-rt/darwin-plistbuddy-workaround.patch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Darwin-only?
++ lib.optional stdenv.hostPlatform.isDarwin ./darwin-targetconditionals.patch | ||
++ lib.optional stdenv.hostPlatform.isAarch32 ./armv7l.patch; | ||
# Prevent a compilation error on darwin | ||
./darwin-targetconditionals.patch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also darwin-only.
# On Darwin, we only want ncurses in the linker search path, because headers | ||
# are part of libsystem. Adding its headers to the search path causes strange | ||
# mixing and errors. | ||
# TODO: Find a better way to prevent this conflict. | ||
ncursesInput = if stdenv.isDarwin then ncurses.out else ncurses; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a general problem on Darwin or only for swift packages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this may be specific to the LLVM modules logic, because if it was broader, I feel like we would've encountered it elsewhere. If so, it's possible ObjC can also cause this (maybe even C? I believe the flag is -fmodules
.)
Maybe we should eventually get rid of some of these headers in libsystem. It currently ships headers for ncurses, sqlite, krb5, maybe more, but we package those separately (and libsystem doesn't even provide implementations of those). A similar discussion came up in: #186251 (comment)
e7f08ca
to
6a3c17e
Compare
While trying to build mpv, I noticed it invokes the compiler as The build for mpv then fails with the same CoreVideo error as my little SwiftUI test app. Still debugging that issue. |
6a3c17e
to
814fdd1
Compare
Some more tweaks:
I can now build a SwiftUI app! Will try mpv next, but I also rebased on current staging, and need to do a large rebuild. |
814fdd1
to
316a741
Compare
|
Re testing mpv, if it is not built with Swift it should spit out a warning:
It will also not be able to go into fullscreen mode when you press This is probably not a thorough test of the functionality Swift adds to mpv but may be sufficient? |
You're not actually using the new swift UI in that case. You need to add Building with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Darwin stdenv changes look OK to me. Though I'm not so familiar with aarch64-darwin, maybe @thefloweringash can take a look as well?
CoreVideo = lib.overrideDerivation super.CoreVideo (drv: { | ||
installPhase = drv.installPhase + '' | ||
# When used as a module, complains about a missing import for | ||
# Darwin.C.stdint. Apparently fix in later SDKs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Darwin.C.stdint. Apparently fix in later SDKs. | |
# Darwin.C.stdint. Apparently fixed in later SDKs. |
@Atemu, this is a way to test mpv is in fact using the Swift built libmpv. I'm saying if it was not then you'd get that error and fullscreen wouldn't work. This was just advice in response to stephank's edit:
|
Thanks for taking a look. Mpv fullscreen does work in the Swift enabled build (and not with my regular nix-darwin install, as expected), so that's a good sign. For the REPL, it appears the logic is in swift-driver. The |
Would you mind if I extracted this commit and this commit into a separate PR to merge before this is ready? On my aarch64-darwin machine, they resolve building cargo-watch and xcbuild. |
Please do! I had no idea this was broader than Swift. 🙂 |
316a741
to
311a1bb
Compare
I rebased and fixed a conflict with #181764. I don't believe that PR affects Darwin. On Linux, the fix from that PR doesn't appear to be necessary anymore. Binaries for d63aef6 on
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, this work is considerable to say the least. Makes reviewing quite a task.
I'd like to ask to avoid further rebasing while reviews are on-going. Fixup commits are a good option for an autosquash rebase afterwards.
Thank you for the effort that must've gone into this! ❤️
pkgs/development/compilers/swift/compiler/patches/swift-nix-resource-root.patch
Show resolved
Hide resolved
pkgs/development/compilers/swift/libdispatch/disable-swift-overlay.patch
Show resolved
Hide resolved
binPath="$(swiftpmBinPath)" | ||
mkdir -p $out/bin | ||
cp $binPath/sourcekit-lsp $out/bin/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
binPath="$(swiftpmBinPath)" | |
mkdir -p $out/bin | |
cp $binPath/sourcekit-lsp $out/bin/ | |
mkdir -p $out/bin | |
cp "$(swiftpmBinPath)"/sourcekit-lsp $out/bin/ |
The intermediate variable doesn't really add anything IMO.
Where does swiftpmBinPath
come from though, a hook? And do we want to use lib.getBin
with it?
postInstall = (attrs.postInstall or "") | ||
+ lib.optionalString stdenv.isDarwin '' | ||
# The install name of libraries is incorrectly set to lib/ (via our | ||
# CMake setup hook) instead of lib/swift/. This'd by easily fixed by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# CMake setup hook) instead of lib/swift/. This'd by easily fixed by | |
# CMake setup hook) instead of lib/swift/. This'd be easily fixed by |
'' | ||
+ lib.optionalString (!stdenv.isDarwin) '' | ||
# The cmake rules apparently only use the Darwin install convention. | ||
# Fix up the installation so to module can be found on non-Darwin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Fix up the installation so to module can be found on non-Darwin. | |
# Fix up the installation so the module can be found on non-Darwin. |
'' | ||
+ lib.optionalString (!stdenv.isDarwin) '' | ||
# The cmake rules apparently only use the Darwin install convention. | ||
# Fix up the installation so to module can be found on non-Darwin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Fix up the installation so to module can be found on non-Darwin. | |
# Fix up the installation so the module can be found on non-Darwin. |
sed -i -e '/BUILD_SHARED_LIBS/d' CMakeLists.txt | ||
''; | ||
|
||
postInstall = '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe refactor this out, since it's repeated?
|
||
preFixup = lib.optionalString stdenv.isLinux '' | ||
# This is cheesy, but helps the patchelf hook remove /build from RPATH. | ||
cd $NIX_BUILD_TOP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIX_BUILD_TOP
should usually be avoided. I think it doesn't play nice with nix-shell
for example. Is there an alternative way we can do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I combined the glue files in a cmake-glue.nix
, and it also combines these shell snippets needed for installation.
EDIT: This was supposed to be a comment on #189977 (comment)
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
I did a merge with a recent(ish) staging (when I started working on it again), and was able to verify a build on Swift has since released 5.7.1, but we can do that separately. |
Reporting that this branch is of high enough quality that mpv, with some additional |
Fwiw, I believe all feedback is addressed? Not sure what else I should do here. Would be great if we could move this forward! |
I've been waiting for another pair of eyes on this. If that's not forthcoming we can merge though IMO. |
Even if there is some issue you overlooked, I think this is a major improvement over the status quo with no obvious flaws. Any further refinements can always be done afterwards. If you looked over it and everything you found has been addressed, I think it's good enough for staging/unstable. |
Ping! Can we merge this? 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple remaining questions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description of changes
This PR splits up the Swift build into smaller derivations, and brings up Darwin support for the toolchain. Fixes #37473.
I've kept the same maintainers listed as before, also for the new derivations that were already part of the toolchain. Hopefully that's okay, otherwise, let me know.
To perform the split, I've added a
swiftPackages
. It's not very large, but avoids cluttering the global namespace, and helps set up a scope with the required clang, macOS SDK, etc.Tests are a pain point, and I've disabled them in many places. I believe we can fix many of the tests, but it'll take more effort.
Usage
The
swift
attribute now gets you just the Swift compiler (swift
andswiftc
). These tools are now wrapped, and a new setup-hook addslib/swift
of inputs to the Swift include path automatically. This is especially important on Darwin, where we separately package system frameworks.The attribute
swiftpm
installsswift-build
,swift-test
,swift-run
, though these are usually invoked without the hyphen by users (swift build
). Additionally, a new setup-hook provides default build and check phases for convenience.Build process
Previously, our Swift build used the Python-based 'build-script' to build Swift, which I believe matches official Swift CI. This new build bypasses the Python scripts and invokes CMake directly. I personally find this approach better for us, because:
build-presets.ini
patches were becoming hard to stack and maintain.The basic compiler derivation now builds primarily CMark, Clang, and Swift. We also build LLDB, but only because the REPL uses it. On Darwin, there is also some extra work for back-deployment, though I've not actually tested if/how back-deployment works.
On top of this, I implemented a wrapper similar to cc-wrapper.
I've separately packaged Dispatch, Foundation and XCTest. Dispatch is based on an existing derivation, but Swift support was added.
The second complex build is for SwiftPM. We match the official build process here in first doing a CMake build, then using that to build SwiftPM itself. I wrote a small swiftpm2nix tool based on shell + jq, which actually replaces the bulk of the
fetchgit
source derivations from the old Swift build.Beyond that, I also packaged the other parts of the SDK, but believe only sourcekit-lsp is currently useful.
Darwin stdenv
The biggest change to stdenv is that Swift modules are installed. These are
os
andDarwin
for libsystem, and per-framework Swift overlays where available. I do have a small list of modules from the SDK that I couldn't place yet:I skipped these to limit time spent polishing details, and hope we can fix these as they become an issue.
Maybe it's possible to avoid these changes to existing SDK derivations by having separate derivations for all the Swift-specific stuff, but I haven't tried this, and wonder if it's worth it. Apple seems to treat Swift more and more as a core part of the system, and it'd make packaging a bit more tedious.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes