| 19 Nov 2024 |
 emily | (with Nix work) | 19:33:21 |
 p14 | But even if you split testing you could still have stuff whose build unfortunately depends on implementation and not just the interface. | 19:33:22 |
| emily | tests don't have to block the build | 19:33:27 |
| emily | as long as they prevent it from being successful if they fail | 19:33:35 |
| p14 | “Ninja’s validations”? | 19:33:46 |
| emily | so tests are much more embarrassingly parallelizable in theory | 19:33:48 |
| emily | uhh, it was discussed in the thread :) | 19:33:53 |
| p14 | Flew over my head if so, apols. | 19:34:13 |
| emily | you can say that build X only succeeds if build Y succeeds, but unlike "X depends on Y", build Z that depends on X can run before Y completes | 19:34:36 |
| emily | https://ninja-build.org/manual.html#validations | 19:34:42 |
| emily | this means that tests could basically happen in parallel to each other and all the relinking | 19:34:55 |
| emily | you don't have to finish the tests for libfoo to test application bar that depends on libfoo | 19:35:05 |
| emily | they can run simultaneously | 19:35:08 |
| emily | (though again this would require support in Nix) | 19:35:11 |
| emily | as far as "But even if you split testing you could still have stuff whose build unfortunately depends on implementation and not just the interface." goes, it would be statically ruled out by the scheme – with only the stubs, things would just not run | 19:35:33 |
| emily | stuff that absolutely needs it would have to have the bits that need runtime support split out (ties in to the cross conversation we just had in here actually), or to depend directly on relinked stuff and thereby be exempt from the scheme | 19:35:57 |
| p14 | Seems like it would be potentially quite a substantial nixpkgs rearchitecting to be able to run tests in a separate derivation, or do you see a route which would not require this? | 19:37:53 |
| emily | yes, this whole thing would be very substantial :) | 19:38:54 |
| emily | it's probably not something we could realistically migrate to, it's more very good ideas for the next thing that comes along | 19:39:12 |
| emily | the alternative is to fold checks into the derivation that does the relinking which would be not quite as burdensome | 19:39:33 |
| emily | but reduce the parallelism advantages | 19:39:37 |
| emily | (and it's much more installCheckPhase-oriented than checkPhase) | 19:39:51 |
| 20 Nov 2024 |
|  Inayet removed their profile picture. | 00:59:04 |
 Randy Eckenrode | Posting this here too. I reduced the number of Clangs Darwin needs to cross-compile. | 19:28:41 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/357633 | 19:28:42 |
|  truby joined the room. | 21:08:45 |
| 21 Nov 2024 |
 Tristan Ross | https://github.com/NixOS/nixpkgs/pull/348192 might be good for someone to look at this, I'll fix the conflicts soon. | 15:00:17 |
| 22 Nov 2024 |
|  Morgan (@numinit) joined the room. | 17:50:23 |
| 23 Nov 2024 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/335023 anyone around to look at this? I kinda want to use an LLVM kernel but this PR is blocking that. | 05:30:46 |
| emily | while I like the end result, I'm also sceptical of the as32bit/as64bit thing. like is there any AArch64 hardware that implements ARMv5? some of these don't make sense to couple to me | 05:33:29 |
