| 19 Nov 2024 |
 sterni | and often you'd need to test cross anyways, then it makes no difference anyways | 14:23:32 |
 emily | I don't think hacks like #351768 are cleaner than int main(int argc, char **argv) { execvp(argv[1], argv+1) }. | 14:24:12 |
| sterni | but yeah vendoring exec(1) is also an option, but it's also kind of silly | 14:24:15 |
| emily | I think adding >100 builds to the cycle time of testing compiler changes is painful | 14:24:43 |
| emily | it's not about "emulator tests" | 14:25:02 |
| emily | the emulator is used so that the cc-wrapper tests support both cross and native | 14:25:10 |
| emily | there's nothing to skip | 14:25:22 |
| 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 |
