| 1 Dec 2025 |
 K900 | It just won't have glx | 17:34:51 |
 emily | well… | 17:34:58 |
| emily | that's not very useful | 17:35:00 |
| K900 | I think it might even have egl? | 17:35:05 |
| K900 | Not sure | 17:35:07 |
| emily | no, no EGL on macOS. | 17:35:13 |
 Randy Eckenrode | No, just Apple GLX. | 17:35:20 |
| K900 | But also like, there's like five things that depend on it | 17:35:24 |
| K900 | In all of nixpkgs | 17:35:27 |
| K900 | Why do we even care at this point | 17:35:36 |
| Randy Eckenrode | There does seem to be some desire to get Zink working on Darwin. | 17:35:59 |
| emily | I have actually used XQuartz to run something as recently as the past couple years. admittedly I did not use the Nixpkgs version | 17:36:00 |
| Randy Eckenrode | Maybe we could build that eventually. | 17:36:08 |
| K900 | I mean zink on kosmickrisp is valuable even without GLX | 17:36:34 |
| Randy Eckenrode | I ran XQuartz several years ago to run the file manager they used in Jurassic Park. | 17:36:34 |
| emily | admittedly the last time I had to do remoting of Linux GUI apps I used xpra | 17:36:40 |
| K900 | Because it's better GL support than Apple has | 17:36:41 |
| emily | though xpra on macOS is kind of crap too | 17:36:45 |
| K900 | But that's a VERY DIFFERENT THING | 17:36:46 |
| emily | I suppose once GTK and Qt drop X11 support the remoting use case will disappear 🤪 | 17:37:18 |
| emily | maybe we'll just get waypipe working on macOS. | 17:37:29 |
| emily | anyway re: merging I was mostly just thinking that if Darwin is going to be a supported target the issues with the build being blocked on Darwin will be significantly mitigated, and it doesn't seem compelling to keep them separate in that case. | 17:38:12 |
| K900 | Well the expressions will share basically nothing | 17:39:33 |
| K900 | Because 95% of it is still Linux specific | 17:39:42 |
 samasaur | In reply to @reckenrode:matrix.org
The issue is more that our update plans involve removing the 14.4 SDK next year. how terrible would it be to keep the 14.4 SDK around for swift bootstrapping? not to expose it to all of nixpkgs, but just for the bootstrap swift | 17:41:17 |
| samasaur | my impression is that since the SDK rework, maintaining a specific version of the SDK is not inherently difficult, and all the actual challenges come from packages using that SDK | 17:42:33 |
| Randy Eckenrode | We could keep the version information around but not provide the attribute. Swift could build with a special stdenv using that SDK. | 17:44:52 |
| samasaur | yeah that's kinda what im thinking | 17:45:14 |
| samasaur | bc a new SDK version is just a URL and hashes, right? | 17:45:32 |
| Randy Eckenrode | The major version is an argument to the SDK derivation. We would just need to keep the old SDK version files around for that. | 17:46:57 |
