| 17 Apr 2026 |
 viraptor | It seems to essentially rewrite the .xcodeproj into a json form. And yeah, I'm just looking into adding that. There are some elements that are not parsed properly for swift too, so it's going to be "fun". | 21:26:43 |
| viraptor | (especially since I haven't done C++ in like 2 decades...) | 21:28:32 |
 Randy Eckenrode | If we just need to reserialize it, can we use one of the existing tools to dump the project unto JSON? | 21:29:30 |
| Randy Eckenrode | * | 21:29:38 |
| Randy Eckenrode | * | 21:30:36 |
| viraptor | Not sure what you mean by existing libraries in this context.
But it looks like the translation to .pif is relatively trivial. Just waiting for all-the-things to rebuild due to xcbuild changing 😒 I'll submit something this weekend. | 22:36:35 |
| Randy Eckenrode | I mean like use one of the existing Python pr Ruby libraries to parse the project and dump it out in the correct JSON format. It avoids needing to mess with xcbuild and go through lots of rebuilds. | 22:50:09 |
| Randy Eckenrode | Otherwise, if you do need to modify xcbuild, I would suggest creating a temporary xcbuild2 package that you can modify without doing lots of rebuilds. | 22:50:52 |
| Randy Eckenrode | * | 22:51:00 |
| Randy Eckenrode | * | 22:51:37 |
| Randy Eckenrode | * | 22:51:44 |
| viraptor | Right. I was just thinking about how much that can be untangled from the apple sdk a bit. The strict path lookup from various things makes it hard (xcode-select and then running things under that path). But it's ok, we'll get there. | 22:53:02 |
| Randy Eckenrode | I would just patch that stuff out. Swift Build already requires a ton of patching due assuming FHS. | 22:56:43 |
| 18 Apr 2026 |
| Randy Eckenrode | Looks like KosmicKrisp is going to be getting tessellation soon-ish. Some ground work MRs have landed recently. Mesa 26.2 should be interesting. | 00:03:20 |
| Randy Eckenrode | … is Rubberband broken with libc++ 21? | 01:17:24 |
| Randy Eckenrode | Yes. https://github.com/breakfastquay/rubberband/pull/126 | 01:29:25 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/511070 makes GNU libiconv the default on Darwin. I keep tripping over autoreconfHook causing breakage …. | 03:32:56 |
|  @lain:glasgow.social left the room. | 04:32:43 |
| viraptor | In reply to @reckenrode:matrix.org
I would just patch that stuff out. Swift Build already requires a ton of patching due assuming FHS. It's all going in the right direction. There are a few changes in xcbuild, ibtool and others, but... I'm confident things will work in the end. swbuild itself is behaving well. | 07:33:46 |
| viraptor | * It's all going in the right direction. There are a few changes in xcbuild, ibtool and others, but... I'm confident things will work in the end. swbuild itself is behaving well.
(There's at least 2 utilities to shim/rewrite to make it work. Currently dealing with derq) | 09:05:52 |
 WeetHet | I wish that making vulkan loader use mesa didn’t feel as hacky. I know that it uses moltenvk only in one place and using override { moltenvk = mesa; } works but it feels wrong
Gtk4 doesn’t use vulkan on macOS for now due to the visual artifacts with moltenvk which aren’t present with mesa
| 11:18:13 |
| Randy Eckenrode | Can’t apps that need Mesa set the environment variable to point at the KosmicKrisp ICD? | 11:19:23 |
 K900 | This makes no sense anyway | 11:19:59 |
| K900 | It should not be linking moltenvk at all | 11:20:08 |
| K900 | It should be linking vulkan-loader | 11:20:12 |
| WeetHet | https://github.com/NixOS/nixpkgs/blob/a9503707cb403de2b9a974c27d89031c73b84455/pkgs/by-name/vu/vulkan-loader/package.nix#L52 | 11:20:41 |
| K900 | Yeah that's a hack | 11:21:00 |
| K900 | If GTK links vulkan-loader you can set the environment variables | 11:21:14 |
| K900 | And point it at kosmickrisp | 11:21:16 |
| Randy Eckenrode | That’s a default path, isn’t it? | 11:21:19 |
