| 10 Sep 2025 |
 K900 | Windows has its own OpenGL implementation | 20:31:26 |
| K900 | And its own WSI | 20:31:31 |
| K900 | (well, OpenGL doesn't really have WSI, but it has WGL which Mesa does not implement) | 20:31:56 |
 Artturin | https://github.com/NixOS/nixpkgs/blob/0e70d509032143c409a48178c717a42d1fb109e3/pkgs/development/libraries/mesa/default.nix#L277 for shebang lol | 20:32:27 |
| K900 | Point being, you can't cross compile Mesa and produce an application that will be usable on Windows | 20:32:37 |
| K900 | And if you want to make an application that uses OpenGL on Windows, you don't need Mesa | 20:33:10 |
| K900 | If you want a platform abstraction, you probably want something like https://gen.glad.sh/ | 20:34:44 |
 frontear | Yeah I didn’t expect it to be usable, I mostly just wanted to test if it would compile as a simulation for whether or not lecturers could compile my software on their end, just to be safe. | 20:37:00 |
| frontear | I suppose throwing together a VM shouldn’t be too hard for something like this | 20:37:18 |
| K900 | You are not going to get an environment that's representative of whatever your lecturers will be using | 20:37:30 |
| K900 | Assuming they're on native Windows + MSVC | 20:37:38 |
| frontear | Yeah that’s an excellent point, so I should definitely get a proper machine going for this. | 20:38:35 |
| K900 | If you're doing MinGW it will definitely break | 20:38:55 |
| K900 | If you're doing LLVM with MSVC ABI and Windows SDK headers, nixpkgs will explode and it will still break if you end up using any clang-isms | 20:39:28 |
| K900 | But an MSVC/WinSDK shaped target is something that nixpkgs just doesn't have | 20:40:53 |
| K900 | And it will take a lot of work to make it happen | 20:41:00 |
| frontear | That’s insightful thank you. I’ll go get an actual system setup for my sake then | 20:42:33 |
 rosssmyth | We are working on it!
#windows:nixos.org | 23:49:05 |
| rosssmyth | Progress is being made | 23:49:24 |
| 11 Sep 2025 |
|  Ihar Hrachyshka joined the room. | 00:07:24 |
 Winter | Can I get an explanation of the propagation mapOffset stuff? I know that e.g. if I want something in nativeBuiildInputs to propagate to buildInputs, depsTargetTargetPropagated is the way, but no mater which way I subtract/add the offsets, nothing is consistent enough that I trust my math is right. | 13:24:39 |
| 12 Sep 2025 |
| rosssmyth | How is one supposed to write tests to ensure cross-compilation continues working if you are not supposed to write "pkgsCross" in derivations | 01:30:57 |
| rosssmyth | including for passthru tests | 01:31:19 |
| rosssmyth | Based upon: https://github.com/NixOS/nixpkgs/pull/430515#issuecomment-3148477761 | 01:33:45 |
 emily | I don't see an issue with it for passthru.tests | 01:34:57 |
| emily | other than maybe there might be a technical problem with the "disabling variants in the package set" machinery | 01:35:11 |
| rosssmyth | Apparently there is though | 01:35:44 |
| rosssmyth | John Ericson: Can you provide some insight as to why this should not be done? | 01:37:05 |
| emily | you can probably cheat by import path { … } 🙃 | 01:37:13 |
| emily | maybe ping wolfgangwalther in an issue and ask for his take | 01:37:17 |
