| 19 Nov 2024 |
 emily | to which the answer is, now it means the bootstrap chain for basic tests is a bunch longer, unless we hack around it or strip down the closure | 14:20:57 |
 sterni | you don't need to use canExecute there, just don't test emulator if hostPlatform == buildPlatform if you really care about the speed of the tests | 14:20:58 |
| emily | but the whole point of having a NOP emulator is that you can just use it without needing to replicate that logic everywhere. | 14:21:24 |
| emily | (that wouldn't work for i686 anyway I think) | 14:21:36 |
| 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 |
