| 27 Sep 2025 |
 outfoxxed | If we have multiple host offsets then the hook separates build/target packages, otherwise it doesn't | 20:21:57 |
 K900 | I think the correct way to do Qt6 cross is to always have it be nativeBuildInputs | 20:24:50 |
| K900 | And dispatch on $target | 20:24:58 |
| outfoxxed | The qt packages themselves should potentially depend on their pkgsBuildHost versions in nativeBuildInputs | 20:26:31 |
| K900 | It's extremely stupid | 20:26:31 |
| outfoxxed | but users shouldnt have to | 20:26:33 |
| K900 | No, that's not what I meant | 20:26:41 |
| K900 | I mean that Qt cross is weird enough that we basically want to have Qt always be "on build for target" | 20:27:03 |
| outfoxxed | Yeah currently all the package files pass things via cmake flags to override paths which im not particularly fond of | 20:27:05 |
| K900 | And target-aware | 20:27:16 |
| outfoxxed | so far I've successfully crossed everything to riscv64 using the hook stuff above but I'm going to try removing all the special casing from the nix expressions and just hoping QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH does what its supposed to | 20:28:11 |
 Alyssa Ross | Nice! | 20:28:26 |
| outfoxxed | Its rather unhelpful that every single test run takes 45 minutes to build | 20:28:52 |
| K900 | Push it | 20:29:25 |
| K900 | cmake cross might just be the thing I need to get my mind off being fired from moderation | 20:29:36 |
| outfoxxed | alright | 20:29:36 |
| outfoxxed | cmake cross is a thing | 20:29:44 |
| outfoxxed | that part works fine | 20:29:47 |
| outfoxxed | its qt's self referential dependencies | 20:29:56 |
| K900 | I am aware, and it's horrible | 20:29:58 |
| outfoxxed | I also changed all the pkgsBuildBuild instances to pkgsBuildHost because pkgsBuildBuild makes me rebuild the (qt) world 3 times instead of 2 | 20:30:46 |
| outfoxxed | will send the branch in a minute | 20:32:50 |
| outfoxxed | 
Download image.png | 20:32:51 |
| outfoxxed | https://github.com/NixOS/nixpkgs/compare/master...outfoxxed:nixpkgs:qt-stuff
currently at the stage of narrowing down what I can remove while having it still work | 20:33:56 |
| outfoxxed | and trying to move things to nativeBuildInputs | 20:34:13 |
| outfoxxed | K900: do all the qt packages use propagatedBuildInputs for the purpose of making sure the deps are caught by the hook and make it into the user's cmake env? | 20:36:45 |
| K900 | It's not entirely consistent | 20:37:32 |
| K900 | kdePackages shoves everything into propagatedBuildInputs because upstream metadata is structured that way | 20:38:10 |
| K900 | And we rely on that | 20:38:10 |
| outfoxxed | ah | 20:38:25 |
