| 13 Jun 2025 |
 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 |
