| 25 May 2025 |
 Randy Eckenrode | * Note that it’s not possible to write a function to replace inputs that works in all cases because not all dependencies are in buildInputs (or propagatedBuildInputs). It’s the same problem that overrideSDK had. You’ll always need to know what dependencies your inputs have to make sure there are no problems. | 15:15:44 |
 Tristan Ross | In reply to @reckenrode:matrix.org
Note that it’s not possible to write a function to replace inputs that works in all cases because not all dependencies are in buildInputs (or propagatedBuildInputs). It’s the same problem that overrideSDK had. Yeah, I have thought about a recursiveStdenvOverride function which might work here | 15:30:31 |
| Tristan Ross | It would go through and apply the new stdenv where it should apply. | 15:30:54 |
| Randy Eckenrode | That can’t be done in the general case. Would it be possible to have a function like yesReallyDoInstantiateAnotherNixpkgsWithStdenc for non-trivial cases? | 15:31:47 |
| Randy Eckenrode | * That can’t be done in the general case. Would it be possible to have a function like yesReallyDoInstantiateAnotherNixpkgsWithStdenv for non-trivial cases? | 15:31:59 |
| Tristan Ross | Idk | 15:32:48 |
| Randy Eckenrode | Thinking about Wine, it has a number of vendored dependencies that would be nice to devendor. It would also be nice to build wine-mono and wine-gecko from source. | 15:32:54 |
| Randy Eckenrode | I would not want to have to manually override all the dependencies to build Gecko or Mono. | 15:33:22 |
| Tristan Ross | Yeah, it seems like no matter what, cross compilation is always going to be expensive but necessary. | 15:34:39 |
| 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 |
| Tristan Ross | And you could override the unwinder, cxxlib, etc | 15:53:00 |
| Tristan Ross | I think I've seen clang get rebuilt for cross so being able to not have to rebuild clang when doing cross would be nice | 15:54:05 |
| Randy Eckenrode | Clang shouldn’t be rebuilt for cross anymore. Only the wrapper now. | 16:44:06 |
| Randy Eckenrode | Darwin bintools shouldn’t need rebuilding either, but that work hadn’t been done yet. | 16:45:14 |
