| 22 Oct 2025 |
 emily | (nothing concrete though, it is in the design phase, but a lot of effort has been spent on it) | 01:35:59 |
| emily | ("everything in by-name without compromises" is a 26.05 goal for me) | 01:36:20 |
 Randy Eckenrode | This is what my branch had before I ran out of time to work on it: https://github.com/reckenrode/nixpkgs/blob/aff41926b0a296636319aca01255118a94132d7f/pkgs/development/compilers/swift/default.nix. | 01:36:23 |
| Randy Eckenrode | With Swift 6.2 supporting a C++ bootstrap, I’m going to be simplifying it and getting rid of versions.json. | 01:36:35 |
| Randy Eckenrode | I would really like to see LLVM get a proper scope, so that overrides work. | 01:37:27 |
| emily | Lun has a PR fixing the rebuild issues with that | 01:38:13 |
| emily | not sure if there are any blockers; cc Lun? | 01:38:24 |
| emily | I remember some issue but i forget what | 01:38:28 |
| Randy Eckenrode | Yeah. It sort of stalled? | 01:38:29 |
| emily | LLVM has been a fun case to think about for by-name, since it is both a fairly complicated splicing-requiring scope and multi-version | 01:39:05 |
 Katalin 🔪 | In reply to @emilazy:matrix.org
^ oh! neat! | 01:40:56 |
| Randy Eckenrode | The direction I would like to go is swiftPackages.swiftc is the compiler. swiftPackages.swift is swiftc plus swift-driver and so on. | 01:42:05 |
| Randy Eckenrode | That way swiftPackages.swift-driver is the same thing that the compiler has. | 01:42:15 |
| Randy Eckenrode | And also add swiftPackages.stdlib, so it can do cross in a not crazy way. | 01:42:32 |
| Randy Eckenrode | I absolutely do not want the kind of nonsense Rust does to let you target WASI. | 01:42:55 |
| Randy Eckenrode | You should just use swiftPackages.swift with the pkgsCross.wasi32.swiftPackages.stdlib or SDK or whatever it ends up being. The non-wrapped Swift will be multitarget. | 01:43:22 |
| Randy Eckenrode | I wanted it to work with local workflows using Swiftly to install other SDKs. | 01:43:32 |
 Lun | In reply to @emilazy:matrix.org
not sure if there are any blockers; cc Lun? Got stuck trying to get it to 0 rebuilds on darwin stdenv stage override issues i don't (yet) comprehend | 01:48:36 |
| Lun | https://github.com/NixOS/nixpkgs/pull/445668#discussion_r2374294779 | 01:49:44 |
| Randy Eckenrode | I added approvals. | 01:51:50 |
| Randy Eckenrode | Instead of inheriting clang, maybe inherit systemLibcxxClang instead? | 01:56:21 |
| Randy Eckenrode | That seems to eliminate all the rebuilds on Darwin for me.
$ nix run github:NixOS/nixpkgs#nix-diff $(nix derivation show github:nixos/nixpkgs/?ref=82b9e372e6d3c71428ce2b67b8e2eaf556cb22a7#legacyPackages.aarch64-darwin.llvmPackages.clang | jq -r 'keys[0]') $(nix derivation show .#legacyPackages.aarch64-darwin.llvmPackages.clang | jq -r 'keys[0]')
| 02:05:04 |
| Randy Eckenrode | Returns nothing. | 02:05:07 |
| Randy Eckenrode | (I went with that instead of staging-next because I assume staging-next has moved on since then.) | 02:05:54 |
| Lun | Thanks! Will apply that and rebase soonish | 02:12:09 |
| Randy Eckenrode | If I have time this week, I’d like to update ld64z | 11:07:31 |
| Randy Eckenrode | * | 11:07:37 |
 Ihar Hrachyshka | some weird failure on staging darwin in pkgsCross.wasi32.llvmPackages.libcxx which is a mozilla builder dependency.
Some low level toolchain issue looks like: https://github.com/NixOS/nixpkgs/issues/454709
A bit over my head on first sight. I wonder if someone has ideas what's going on there. | 23:20:24 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/442945 | 23:24:16 |
| Randy Eckenrode | May need to disable the hardening when building for WASI. | 23:25:03 |
