| 19 Nov 2024 |
 p14 | emily: I’ve been thinking a bit about what you were saying about separation of interface vs implementation for CA builds. One concern is: if you switch out the implementation, should that not also require a rebuild of downstream software which uses the implementation during the build at least?
I was thinking of the openssl case where ideally updating openssl doesn’t require a rebuild of the world, but as soon as you have a package which in checkPhase exercised the implementation of openssl, that package could be broken by the new implementation but would not have its tests run.
I guess if you depend on the implementation in order to build (or test) then that would require passing the implementation in; and therefore would condition the build on the implementation. I also wonder if I am talking myself into the concept that testing would have to happen in a separate derivation, essentially, which consumes the implementation. | 19:32:34 |
 emily | it would have its tests run – tests would happen after the relinking stage | 19:33:06 |
| emily | you could avoid these being in serial by using something like Ninja's "validations" | 19:33:17 |
| 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 |
