| 29 Nov 2025 |
 Randy Eckenrode | Once I have this working, I want to go back and split out the stdlib into its own package, which should help make cross-compilation possible. It’s not supported currently. | 20:26:45 |
| Randy Eckenrode | I am working on this for 6.2.1, but I plan to land the changes for 5.10.1 first (moving it into the new pattern). 6.2.1 will be a separate PR. | 20:27:38 |
 toonn | That sounds like a solid plan. | 22:55:28 |
| 30 Nov 2025 |
| Randy Eckenrode | So far the alternate approach seems to be working. I can patch sources in Swift packages and then use a hook to expose them to SwiftPM. Unfortunately, the SDK requires observability, which makes the C++-only bootstrap compiler pretty useless. | 04:05:33 |
| Randy Eckenrode | Actually, just importing Foundation blows up the build. | 04:19:57 |
| Randy Eckenrode | This sucks. The 26.0 SDK appears to use macros unconditionally in the Observation module. The 14.4 SDK has guards for when macros are disabled, so the module doesn’t blow up. | 04:25:47 |
| Randy Eckenrode | I don’t know how this bootstrap is going to work in that case. | 04:26:55 |
| 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 |
