| 13 Jun 2025 |
 K900 | It helps but it doesn't fully solve the problem | 19:08:53 |
| K900 | And the problem is that cmake is a giant blob of global state that is entirely shared between build and host | 19:09:07 |
 emily | they do at least have variables that are meant to distinguish the two | 19:17:19 |
| emily | they might not be good at it though | 19:17:21 |
| K900 | The fundamental mismatch here is that in the cmake/qt world, you're supposed to build an entire Qt package as cross | 19:20:55 |
| K900 | And then its crossness is encoded into the output | 19:21:04 |
| K900 | Like, it will just make build tools and host libraries and encode that knowledge into its cmake files | 19:21:20 |
| K900 | And when we try and give it what it thinks are two distinct Qts, one host and one build, it explodes | 19:21:41 |
| emily | why would we give it two? | 19:22:12 |
| K900 | Because one is nativeBuildInputs and the other is buildInputs | 19:22:23 |
| emily | it's okay for a cross-built package to contain buildPlatform tools | 19:22:31 |
| emily | we handle some *-configs like that | 19:22:39 |
| K900 | Because we want it to use the host tools | 19:22:40 |
 Alyssa Ross | This sounds like it should just be in nativeBuildInputs | 19:23:06 |
| K900 | I guess technically the strictDeps-ly-correct way of doing this would be to shove everything into buildInputs | 19:23:06 |
| Alyssa Ross | Same deal as with a compilerr | 19:23:10 |
| K900 | And pretend nativeBuildInputs don't exist | 19:23:12 |
| Alyssa Ross | * | 19:23:14 |
| K900 | Actually yes the opposite | 19:23:25 |
| Alyssa Ross | No, the opposite | 19:23:27 |
| K900 | Because it doesn't search for binaries in buildInputs | 19:23:38 |
| emily | are you sure? that's more targetPlatform in the world | 19:23:40 |
| K900 | But then we have packages like qtsvg or whatever that are literally just a .so | 19:23:50 |
| Alyssa Ross | buildPackages would be for run-on-cross tools | 19:23:51 |
| K900 | And those have to be in buildInputs | 19:23:54 |
| emily | like, FLTK and SDL1 and stuff have *-config tools that go in outputs | 19:24:01 |
| emily | that are for the buildPlatform | 19:24:05 |
| K900 | And we'll be shoving them to nativeBuildInputs | 19:24:05 |
| K900 | For basically no reason | 19:24:12 |
| emily | it seems wrong to have to move every user to nativeBuildInputs when it grows that | 19:24:16 |
