| 19 Apr 2026 |
 viraptor | So swbuild has a few really weird behaviours that we need to configure. BUT! I'm on the linker issues stage now. Most of the compilation works in a strict sandbox. This gets closer and closer to a real solution. | 08:50:41 |
| viraptor | @[Randy Eckenrode] what's the plan with the swift update branch overall? Does it need some work / help, or are you going to just polish it at some point? | 08:54:13 |
 Randy Eckenrode | I am going to descope it to refactor the Swift 5.10.1 build, then fix Linux. I took a break/detour to do some Darwin work. | 10:32:15 |
| Randy Eckenrode | After that, do the Swift 6.x update. | 10:32:30 |
| Randy Eckenrode | Apple keeps changing the bootstrap requirements. I want to have Swift 5.10.1 building to use as a bootstrap compiler. | 10:33:15 |
| Randy Eckenrode | Swift 6.0 and 6.1 required a Swift compiler. Swift 6.2 restored support for building with just a C++ compiler, then Swift 6.3 removed it. | 10:34:29 |
| viraptor | Thanks, that's great to hear you're going to wrap it up. I guess I don't have to rush the app compilation fixes then, but they'll come. (hammerspoon first) I'll also try to get someone interested in co-maintaining in some way. I've got fixes to xcbuild, sigtool, ibtool already. Then creating derq, intentbuilder, probably some other things. I'd rather not become the one person holding all of that. | 10:42:30 |
| Randy Eckenrode | After I land the cleanup for Swift 5.10.1, I plan to do the update to 6.2 or 6.3. | 10:49:19 |
| Randy Eckenrode | Then wash my hands of Swift because what an awful language. | 10:49:36 |
| Randy Eckenrode | Oh, yeah. I also need to spend/waste time building Swift Differentiation on its own because Apple dropped it from macOS 26.4. | 10:51:40 |
| Randy Eckenrode | I updated my branch based on staging this morning and re-pushed it. I hope I don’t have to keep rebasing it this week. That was panful. | 11:01:43 |
 WeetHet | Is it okay to put a build with vulkan support into passthru.tests?
tests = {
pkg-config = testers.hasPkgConfigModules {
package = finalAttrs.finalPackage;
};
darwinVulkanSupport = finalAttrs.finalPackage.override { vulkanSupport = true; };
};
| 13:37:44 |
 K900 | It's fine to have Vulkan in the main build as long as it's not enabled by default IMO | 13:38:56 |
| WeetHet | I mean I would have vulkanSupport only be enable by default on linux | 13:39:44 |
| WeetHet | But I need to check that it actually builds | 13:39:57 |
| WeetHet | Oh, wait, but tests aren't built by hydra by default, are they? | 13:41:18 |
| K900 | They are not | 13:42:30 |
| WeetHet | That's unfortunate. Where do I put the override then so it would be build on darwin (both to ensure that the package doesn't break and so it is in the cache) | 13:44:15 |
| K900 | Can it be enabled on Darwin, just not used by default? | 13:44:37 |
| WeetHet | Randy wanted us to not pull vulkan into the closure by default | 13:45:00 |
| K900 | Do we know the closure size impact? | 13:45:28 |
| K900 | It should be pretty small, I think | 13:45:35 |
| WeetHet | I think vulkan-loader pulls in moltenvk on darwin | 13:45:52 |
| WeetHet | 
Download Screenshot 2026-04-19 at 15.46.33.png | 13:46:38 |
 emily | Qt already pulls it in unconditionally though? | 13:47:06 |
| WeetHet | 20mb is quite a lot | 13:47:07 |
| WeetHet | I don't have any Qt apps installed so I don't have moltenvk | 13:47:46 |
| WeetHet | * I don't have any Qt apps installed so I don't have moltenvk in my system closure | 13:47:53 |
| Randy Eckenrode | No, that’s fine for GTK. I just wanted it off by default for now (for the same reasons K900 gave). | 13:48:17 |
| WeetHet | The default backend is still GL even if vulkan-support is enabled | 13:48:45 |
