| 30 Nov 2025 |
 Randy Eckenrode | We could use the 14.4 SDK for bootstrapping, but we’ll have problems next year when that SDK is dropped. It’s the same problem that Swift 5.8 had this year but worse. | 04:27:33 |
 dotlambda | Does anyone want to step up to maintain python3Packages.psutil? It's a dependency of the Darwin stdenv | 04:29:06 |
 toonn | What is different about Apple's bootstrapping method that they don't run into the problem? Or do they just never bootstrap? | 11:15:35 |
| Randy Eckenrode | They already have a Swift compiler lying around. | 11:32:16 |
| Randy Eckenrode | If you have an existing Swift compiler, you can go straight to building the Swift-in-Swift stuff. | 11:33:15 |
| Randy Eckenrode | * | 11:40:02 |
| toonn | So the macro issue only happens at build time? | 11:55:50 |
| Randy Eckenrode | Building a compiler with macro support requires swift-syntax, which requires a Swift compiler. | 12:15:55 |
| Randy Eckenrode | The easy path would be to use the 14.4 SDK, but our removal schedule means we can’t rely on that or have to do something really hacky to build the bootstrap compiler with it. | 12:18:33 |
| Randy Eckenrode | * | 12:18:52 |
| Randy Eckenrode | It’s possible we don’t need early swift-driver. I need to see what we lose by not building it until the end. | 12:19:26 |
| Randy Eckenrode | My current thinking is to have a special boot.nix that builds a fully functional Swift 5.10.1, which can then be used to build Swift 6.x. | 12:59:48 |
| toonn | Do you just want to avoid having to build Swift twice? Once without and once with macro support? | 13:31:38 |
| Randy Eckenrode | I’m trying to avoid having to build it three times, but I don’t think I can do that. | 14:22:36 |
| Randy Eckenrode | The final Swift compiler should be a fully featured build. From what I can tell, not building with early swift-driver disables some optimizations. We probably want those. | 14:23:22 |
| Randy Eckenrode | So I think build the C++ only compiler then immediately use that to build a compiler with macro support. Use that to build early swift-driver and do a final build of the compiler. | 14:24:14 |
|  @sdier:matrix.org left the room. | 15:36:35 |
 emily | sorry for my limited availability recently, will try to catch up on my GitHub backlog soon; let me know if there is anything high-priority for review | 17:33:33 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/463900 would be nice to make overriding LLVM actually work correctly on Darwin. It’s not high priority, but it’s a nice cleanup. | 17:37:10 |
| Randy Eckenrode | Why is Bison failing to build since I updated my staging branch? 🤨 | 21:29:05 |
| Randy Eckenrode | Oh. I updated darwin.libcxx to the one from the 26.0 SDK. Is this some stupid libc++ thing that breaks Bison? | 21:30:15 |
| Randy Eckenrode | Redacted or Malformed Event | 22:08:42 |
| Randy Eckenrode | It was the libc++ hardening. It breaks with libc++ 20 or newer. | 23:58:32 |
| 1 Dec 2025 |
| Randy Eckenrode | I think I’m going to have to package Swift 5.10.1. The C++ bootstrap compiler is useless. | 03:14:09 |
| Randy Eckenrode | This sucks because eventually the 14.4 SDK will be dropped, so what happens then? | 03:15:36 |
| emily | have you reported the bootstrapping issues upstream? | 03:44:01 |
| emily | I assume that the C++ compiler will become more useful over time | 03:44:14 |
| Randy Eckenrode | The problem is the 26.0 SDK exposes macros unconditionally, which the C++ bootstrap compiler can’t support because swift-syntax is written in Swift. | 04:12:08 |
| Randy Eckenrode | It appears to be working with the 14.4 SDK, but that makes me nervous about the long term maintainability. | 04:12:43 |
| Randy Eckenrode | emily: FYI, KosmicKrisp works with mpv and Wine. It doesn’t implement all the features yet that DXVK requires, but they will eventually. | 04:49:23 |
