| 19 Nov 2024 |
 emily | needing logic to conditionalize it to be something that isn't painful to include in the closure defeats the whole point of having a NOP .emulator for when one platform can execute the other | 14:25:44 |
 sterni | the silly thing is probably having the noop emulator | 15:28:35 |
| emily | why? it lets you uniformly handle native and cross. e.g. https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/ju/jujutsu/package.nix#L95-L107 or gobject-introspection stuff. we should use it more over canExecute if anything. | 15:29:50 |
| 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 |
