| 19 Nov 2024 |
 sterni | it's an emulator that isn't an emulator | 15:30:55 |
| sterni | pkgs.writeShellScript "exec" "exec \"$@\"" | 15:31:25 |
 emily | it's the base case of emulation. handling native and cross uniformly is a good thing | 15:38:09 |
| emily | looks like the shell script approach goes from 330 to 332 builds, so I guess that way is fine | 15:38:22 |
| emily | I'll PR that instead | 15:38:26 |
| sterni | emulation shouldn't be a part of cross compilation, honestly, that's the root problem | 15:43:36 |
| emily | how would you prefer to handle things like gobject-introspection and anything else that requires running the produced binary to end up with a correct build of the resulting package? | 15:44:39 |
| emily | opened https://github.com/NixOS/nixpkgs/pull/357309, will test it now | 15:45:02 |
| sterni | Well I don't deny that it's sometimes necessary, but we shouldn't write emulator-first code since emulation is a crutch for packages that can't be cross-compiled properly. | 15:55:38 |
| emily | it's increasingly common to do things like have binaries generate their own shell completion stuff | 15:56:24 |
| emily | for better or worse | 15:56:27 |
| emily | ideally those would be split out into separate derivations or something and we'd integrate emulators at the Nix level though | 15:56:38 |
| emily | but that's a tall order when we haven't even separated out tests :/ | 15:56:46 |
| sterni | for that I think you can just depend on yourself from buildPackages | 15:56:49 |
| sterni | if your completions are target specific you deserve it | 15:57:11 |
| emily | doesn't really work for tests though (but admittedly emulation is complicated there too) | 15:57:39 |
| emily | I don't love the buildPackages solution since it basically doubles all your builds | 15:58:00 |
| sterni | you build that anyways… | 15:58:59 |
| emily | what do you mean? jujutsu certainly doesn't depend on buildPackages.jujutsu | 16:01:02 |
| emily | though if you mean in the sense that Hydra builds most things for common platforms then sure | 16:01:10 |
| emily | looks like the native emulator has been there since 9c8fd412248ad907eee7547b19bf3f7583d2c411, when the function was added in the first place | 16:06:02 |
| emily | anyway, hopefully everyone should be happy with the shell script, since it doesn't touch execline, doesn't add a C file, and doesn't add any non-trivial builds | 16:07:11 |
| emily | still seems like the man pages ought to be split out of execline for the unrelated reasons that were brought up, but it's not my package | 16:07:31 |
| sterni | yeah the execline situation is well… | 17:50:18 |
| sterni | one maintainer more or less unilaterally integrated them, but I guess no one felt strongly enough to start a row about it so far | 17:50:53 |
| emily | my patches are there if anyone wants them, but I guess they no longer have stdenv-related motivation 😅 | 17:53:50 |
| sterni | In reply to @emilazy:matrix.org
though if you mean in the sense that Hydra builds most things for common platforms then sure yeah… | 18:00:39 |
| sterni | sorry if I've been difficult :) | 18:01:14 |
| emily | eh, it's just a bunch of understandable but colliding priorities I think :) | 18:05:23 |
| emily | execline wants to not worry about its own closure size too obsessively, Nixpkgs tests want to be as cheap as possible to run, cross wants to not depend on execution of the host platform, tests need running, binaries want to dynamically generate things | 18:06:11 |
