| 12 Jan 2026 |
 emily | it does affect what things rebuild the world for staging though | 18:20:22 |
 Randy Eckenrode | That would be the only thing. Is sqlite really not a dependency in the bootstrap? | 18:20:45 |
| Randy Eckenrode | It totally will if Swift ever gets added. | 18:20:58 |
| emily | it's only used via libiconv → ATF → Kyua → SQLite and Python → SQLite | 18:21:11 |
| emily | Kyua pulls in Lua too, SQLite will pull in Tcl soon | 18:21:25 |
| Randy Eckenrode | I’m getting close on Swift. I need to fix it to find the separate stdlib, then I need to see if I can use prebuilts. | 18:22:45 |
| emily | if Swift pulls in SQLite regardless then maybe it's not worth trying to cut it out now | 18:23:06 |
| Randy Eckenrode | Then do Linux, but I think that will be okay with LLVM overrides being only somewhat broken now. | 18:23:07 |
| Randy Eckenrode | * | 18:23:26 |
| emily | are you at the point where you'd like broad architectural review for the Swift stuff btw? not sure what state that stuff has in, have been holding off on looking when there's no PR yet 😅 | 18:23:55 |
| emily | though of course my reliability at looking at stuff is less than I'd like in general lately… | 18:24:07 |
| emily | (will still try to look at that stdenv PR…) | 18:24:16 |
| Randy Eckenrode | I can push a branch where it’s just a big, mega commit. | 18:24:33 |
| Randy Eckenrode | I started over with my previous work as a base. | 18:25:03 |
| Randy Eckenrode | It’s doing things a bit differently. I found a way to make Lix stack overflow with bad recursion. 😂 | 18:25:51 |
| emily | oh dear | 18:26:10 |
| Randy Eckenrode | I accidentally had mutually recursive scopes. Whoops. | 18:26:20 |
| emily | yeah I figured the earlier I give annoying complaints about wild stuff the better :P | 18:26:42 |
| emily | very very excited for Swift Build though | 18:26:53 |
| emily | I am eager to drop xcbuild | 18:26:59 |
| Randy Eckenrode | It’s fixed now and more sensible. | 18:27:04 |
| Randy Eckenrode | Swift Build won’t be able to replace xcbuild unless we develop a driver. The swbuild CLI is too limited. | 18:28:22 |
| emily | 😔 | 18:28:47 |
| emily | because of build systems calling out to xcodebuild or because we can't even use it as a hook profitably? | 18:28:55 |
| Randy Eckenrode | There is no way to pass variables. You can’t specify scheme or destination. | 18:30:04 |
| Randy Eckenrode | It can be used as a library, so it should be possible to develop our own frontend, but one needs time to do that. | 18:31:16 |
| Randy Eckenrode | https://github.com/reckenrode/nixpkgs/tree/swift-update-mk2 | 18:34:20 |
| Randy Eckenrode | https://github.com/reckenrode/nixpkgs/blob/swift-update-mk2/pkgs/top-level/swift-packages.nix is where the Swift package set is defined. | 18:34:36 |
| Randy Eckenrode | https://github.com/reckenrode/nixpkgs/blob/swift-update-mk2/pkgs/by-name/sw/swiftPackages/by-name/sw/swift/mk-swift-package.nix is where most of the crimes are committed. | 18:35:11 |
| Randy Eckenrode | The basic structure is swiftPackages.swift defines a package out of swiftc, swift-driver, swift-testing, and swift-corelibs-xctest. I will probably be adding the stdlib as well. That’s the package that should be used. It’s meant to look (more or less) like a normal Swift toolchain. | 18:36:46 |
