| 19 Apr 2026 |
 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 |
| WeetHet | I thought you didn't want moltenvk in the closure by default at all | 13:48:57 |
| WeetHet | * The default backend is still GL even if vulkanSupport is enabled | 13:49:42 |
| Randy Eckenrode | No, that’s fine if it makes using KosmicKrisp easier via setting the correct driver variable in a wrapper. If I gave the impression about not wanting MoltenVK in the closure, that was my mistake. It just shouldn’t be the default renderer. | 13:50:25 |
| Randy Eckenrode | emily Let me know if there’s any follow-up to my replies to your questions. Also regarding the 26.4 SDK fix, another reason I wanted to avoid the cctools-port fix is it mentioned decompilation in the PR. I’m not sure how it was used, but I figured it was better to finish my work and independently derive a fix. | 13:51:27 |
| WeetHet | You still need to force it with GSK_RENDERER=vulkan | 13:51:43 |
