| 19 Nov 2024 |
 emily | In reply to @emilazy:matrix.org
the hack works, but it seems basically suboptimal that switching from canExecute to the more general and capable emulator stuff brings in a bunch of stuff, especially in weird platform/cross scenarios (well specifically cross scenarios are fine because they'd be picking another emulator I guess…) | 13:57:14 |
| emily | I don't necessarily think execline should have to be held to the standard of having a reasonable closure although it is a sufficiently simple package that it doesn't seem overly burdensome | 13:57:47 |
| emily | but like if it suddenly started depending on ShellCheck or something that would be quite awful for the return value of the nop case of a core lib function | 13:58:10 |
 Randy Eckenrode | If we do switch to emulators for things, that would open up using Rosetta 2 for aarch64- to x86_64-darwin cross. (I have started and stopped adding it several times, but it always seems pointless if it can’t be used to run tests.) | 14:06:48 |
| emily | tests are harder I think | 14:07:47 |
| emily | but it's used for some things in the tree | 14:07:51 |
| emily | e.g. completions | 14:08:14 |
| emily | and gobject-introspection nonsense | 14:08:27 |
 sterni | emily: but we always pull in a bunch of stuff for cross, I don't understand the concern?! | 14:18:29 |
| sterni | you always need to bootstrap the full native stdenv for cross tools | 14:19:09 |
| emily | sorry, I misspoke; I think the problem is more non-cross. if you change something in stdenv and want to verify tests.cc-wrapper.default, then it's 100 more rebuilds with current execline unless it's hacked around in those tests, just to fetch manpages etc. | 14:20:03 |
| emily | which we've hacked around in tests.cc-wrapper.default, but it just in general seems bad for a basic lib function that is trying to accomplish literally a NOP to pull in all that stuff, when it was only switched to execline in the first place because "well, it's already there so why duplicate it?". | 14:20:33 |
| 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 |
