| 15 Nov 2024 |
 p14 | Yes, as in, removed from compiler, and verified gone from NIX_DEBUG output of the compiler wrapper. Doing 15 now. | 11:41:49 |
| p14 | I was originally going to stage this as moving it to the compiler wrapper, now I'm toying with just dropping it. | 11:42:18 |
| p14 | But maybe staging it by moving it to the compiler wrapper would be better if it needs to be reintroduced. | 11:42:39 |
 aleksana (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
actually patch up all the indirect references Thoughts: - we'd better take back control of how packages are provided to users from nix, especially in the nix3 shell and run
- pkgs is just one layer, but we can actually have several (or just two), and the bottom one is the unmodified build result, which is also stored in the cache.
- the process of wrapping or linking binaries can be written in an upper-level derivation, and these derivations should prefer local builds
| 11:47:16 |
 emily | you can do it at the fixed point level | 11:49:09 |
| emily | the resulting package set interface could be the same | 11:49:14 |
| emily | you'd probably want some splicing-y .__stubs type stuff 🫣 | 11:49:24 |
| emily | I think it's fine to do the relinking builds on Hydra though (probably) | 11:49:42 |
| aleksana (force me to bed after 18:00 UTC) | Yes, we can still provide the default one | 11:50:11 |
| aleksana (force me to bed after 18:00 UTC) | It's just that we have to save two copies now | 11:50:27 |
| aleksana (force me to bed after 18:00 UTC) | And probably necessary to split out checkPhase so that the library itself doesn't show up in the build closure of stub derivation | 11:52:44 |
| aleksana (force me to bed after 18:00 UTC) | Then with CA you can say it must be the same | 11:53:20 |
| aleksana (force me to bed after 18:00 UTC) | So no rebuilds | 11:53:26 |
| emily | checkPhase stuff was covered in the thread | 11:53:27 |
| emily | but really wants Nix changes too | 11:53:31 |
| p14 | In reply to @emilazy:matrix.org
definitely try 15 15 is fine as well | 11:57:53 |
| emily | 🤔 | 11:58:00 |
| emily | we could just drop it. I imagine wrapped compilers in development shells looking at /usr/include might be upsetting to some, though, if that's a thing that will happen | 11:58:33 |
| p14 | Oh right, that could be a problem if someone uses nixpkgs on a on-nixos system. :( | 11:59:00 |
| emily | well, but, we do pass all sorts of -isystem and -sysroot stuff | 12:00:11 |
| emily | so I dunno if it comes up or not | 12:00:19 |
| p14 | Still could be a problem if extra stuff is in the include search path | 12:00:31 |
| emily | extra stuff like? | 12:00:48 |
| emily | not denying it could be a problem, just want to understand the scenario better | 12:00:56 |
| p14 | At least it could manifest as the underspecified dependency problem: user thinks it's working, but it's only working by accident because they have stuff in /usr/include. | 12:01:04 |
| p14 | And then separately I don't know if we can assume those things defer to the wrapper's -i-flags in precedence or not. | 12:02:01 |
| emily | honestly the real solution is a proper sysroot or something (but there were issues with that too last time it was talked about in here) | 12:02:53 |
| p14 | How do you define "proper sysroot" and how does it help if the compiler can look somewhere you don't want it to look? | 12:03:18 |
| emily | really though there's so many ways for impurities to leak in outside of the sandbox | 12:03:20 |
| p14 | fair. | 12:03:29 |
