| 19 Nov 2024 |
 sterni | I think it's worse to have like weird code for no reason that relies on bootstrapping logic | 14:21:56 |
| sterni | that's always a recipe for having to debug some eval problem for a week down the road | 14:22:17 |
 emily | ok. then can we go back to just vendoring a 5-line C program? | 14:22:17 |
| emily | that would solve all the issues and be even fewer builds | 14:22:26 |
| emily | and execline can do whatever | 14:22:32 |
| sterni | no I'd say just use buildPackages.execline honestly, it's the simplest and cleanest | 14:22:48 |
| sterni | the problem just affects nixpkgs developers and we can just split the tests up, so you don't run the emulator tests if you're in a hurry, right? | 14:23:15 |
| 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 |
