| 13 Jan 2026 |
 Randy Eckenrode | Regarding the bootstrap, what I would like to do is define stage 1 as “bootstrap tools can build most things”. From there, build stage 2 with stage 1 as the host platform and stage 2 as the target, then do that again with stage 2 and 3 as host and target. | 12:26:55 |
| Randy Eckenrode | Stage 4 would be the only overlay stage that sets up the stage 3 compiler such that stage 4 can be host and target. | 12:27:23 |
| Randy Eckenrode | One issue I can see with a cross-like bootstrap is it will pull in more packages and build more things, which people may not like. | 12:33:20 |
| Randy Eckenrode | Also, if we ever add Swift to the bootstrap, that is going to pull in a ton of crap. | 12:33:43 |
| Randy Eckenrode | This exercise to remove sqlite feels pointless if we want to include Swift because it will put it right back in the bootstrap. | 12:34:18 |
 emily | what does Swift pull in anyway? | 12:56:16 |
| emily | I'm curious what it's using SQLite for | 12:56:33 |
| emily | but yeah I didn't mean to set @samasaur:matrix.org out on the errand with a guarantee that we'd want to do it :) just that it seemed worth exploring | 12:57:06 |
| Randy Eckenrode | Caches. | 12:57:07 |
| Randy Eckenrode | I think something is pulling in Rust. | 12:57:38 |
| emily | uh, yeah Rust in the bootstrap might be one to avoid 😅 | 12:58:15 |
| emily | I think we could still trim down closures with a cross setup, right? it'd just be a set of overrides for the build platform | 12:58:51 |
| Randy Eckenrode | Swift and (maybe more so) SwiftPM appear to favor using SQLite to record build information. | 12:59:04 |
| emily | mostly the less stuff in the bootstrap the less annoying it is to test updates on Darwin for them | 12:59:28 |
| Randy Eckenrode | Can we define a platform that simply never runs tests? | 12:59:34 |
| emily | sure why not. I mean cross conditions them on canExecute anyway | 13:00:05 |
| Randy Eckenrode | Like only stage 3 would run tests. It would trim down some of the dependencies. | 13:00:18 |
| emily | I imagine we could cook up a global config option if one doesn't already exist | 13:00:26 |
| emily | no there's just nothing forcing us to clean up after people move away from old crap like scons | 13:01:34 |
| emily | they're in the list solely for a check that they don't get built multiple times during bootstrap | 13:02:10 |
| emily | so <=1 builds passes | 13:02:22 |
| emily | and the scons override is just dead code | 13:02:30 |
| emily | if you want to continue then I'd try bisecting feature flags between python3Minimal and our python3-bootstrap. some of the additional stuff is needed for Meson and the LLVM build system, but it's likely to can find lots of stuff to turn off that trims packaged from the final list without breaking the build | 13:04:26 |
| emily | again with no guarantee that we'll want to actually do that but | 13:04:40 |
| emily | I think it'll be educational if nothing else | 13:04:49 |
| emily | (and I personally think trimming such does is worthwhile because it lowers the things we get pinged for to check after it turns out they rebuild the bootstrap) | 13:05:23 |
| emily | (but ofc if Swift is going to pull in lots of stuff in a more non-negotiable way - maybe the effort just gets undone soon) | 13:05:51 |
| Randy Eckenrode | Swift pulls in Rust because Swift Build is using oxipng for https://github.com/reckenrode/nixpkgs/blob/swift-update-mk2/pkgs/by-name/sw/swiftPackages/by-name/sw/swift-build/extra-bins/copypng | 13:44:59 |
| Randy Eckenrode | We can use something else that doesn’t pull Rust. Just need the flags. | 13:45:26 |
| emily | or we can just make it not use compression during bootstrap? | 13:46:53 |
