| 25 May 2025 |
 Tristan Ross | Ericson brought up that crossStdenv could be done easier with the GCC rewrite he's been trying to push | 15:37:23 |
| Tristan Ross | And there's things crossStdenv uses that should have us make changes to the CC wrapper and the toolchain attributes PR would make things nicer as well. | 15:38:13 |
 Randy Eckenrode | It makes sense to have a crossStdenv for trivial cases that just need a compiler, but sometimes a package set is actually needed. A stdenv adapter won’t be good enough as a substitute. Darwin went through that with the SDK. Overriding the SDK in Rust packages was a major problem and often didn’t work. | 15:41:27 |
| Randy Eckenrode | Also note that such an adapter can’t be written recursively. My first attempt at a general adapter used recursion. Eval performance increased by over 500%. I had to use builtins.genericClosure to do it with good performance. | 15:42:07 |
| Tristan Ross | Ideally, it would be nice if we could have a way to "pull back" the stdenv to stage 3 and then inject new stages in. | 15:43:58 |
| Tristan Ross | Then we could overlay that and it hopefully wouldn't have to eval stages before the new stages. | 15:44:26 |
| Randy Eckenrode | I’d prefer to view the stdenv bootstrap as a black box so that implementation details don’t become fixed API. | 15:47:48 |
| Tristan Ross | True though we'd have to do something to the stdenv for it to be able to do cross unless we split CC away from the stdenv. | 15:48:47 |
| Randy Eckenrode | Darwin’s stdenv bootstrap has changed a lot. The SDK update dropped several stages last fall. | 15:49:04 |
| Randy Eckenrode | I wish the stdenv bootstrap could be structured like a cross from bootstrap tools to final environment. | 15:49:17 |
| Randy Eckenrode | Let the standard cross-compilation machinery take care of building things for the right platforms instead of having to micromanage a bunch of overrides. | 15:49:38 |
| Randy Eckenrode | Then from there you could cross to another platform. | 15:49:53 |
| Randy Eckenrode | I wonder if some of the hard-coded stuff could be removed. Right now, stdenvNoCC is an override of stdenv. Could it be the other way? stdenv is stdenvNoCC with the requisite compilers as extra packages? | 15:51:19 |
| Tristan Ross | Yeah, that's what I'm thinking | 15:51:36 |
| Randy Eckenrode | IIRC wasn’t there some talk about that for libc++ once libstdc++ gets split out of gcc? | 15:51:42 |
| Tristan Ross | Idk but probably | 15:52:01 |
| Tristan Ross | It would be nice to be able to view the stdenv as just tools and CC as the actual C toolchain | 15:52:42 |
