Sender | Message | Time |
---|---|---|
25 May 2025 | ||
DXVK uses a custom MinGW (with the Win32 thread model instead of the POSIX one). When you build https://github.com/NixOS/nixpkgs/blob/6fb6fd3ceff99de72d881f1a97773647c94e5a82/pkgs/by-name/dx/dxvk/package.nix#L28-L44 DXVK itself has dependencies: https://github.com/NixOS/nixpkgs/blob/6fb6fd3ceff99de72d881f1a97773647c94e5a82/pkgs/by-name/dx/dxvk_2/package.nix#L74-L81 The replacement sounds like I need to manually enumerate the transitive dependencies of DXVK, replace all of their | 15:08:53 | |
crossStdenv is still expensive, but now the maintainability of my package has gone down because I have more work to do to build my package instead of just referencing pkgsCross.mingw32.dxvk_2 and pkgsCross.mingwW64.dxvk_2 . | 15:09:59 | |
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. | 15:15:22 | |
* 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 | |
In reply to @reckenrode:matrix.orgYeah, I have thought about a recursiveStdenvOverride function which might work here | 15:30:31 | |
It would go through and apply the new stdenv where it should apply. | 15:30:54 | |
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 | |
* 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 | |
Idk | 15:32:48 | |
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 | |
I would not want to have to manually override all the dependencies to build Gecko or Mono. | 15:33:22 | |
Yeah, it seems like no matter what, cross compilation is always going to be expensive but necessary. | 15:34:39 | |
Ericson brought up that crossStdenv could be done easier with the GCC rewrite he's been trying to push | 15:37:23 | |
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 | |
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 | |
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 | |
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 | |
Then we could overlay that and it hopefully wouldn't have to eval stages before the new stages. | 15:44:26 | |
I’d prefer to view the stdenv bootstrap as a black box so that implementation details don’t become fixed API. | 15:47:48 | |
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 | |
Darwin’s stdenv bootstrap has changed a lot. The SDK update dropped several stages last fall. | 15:49:04 | |
I wish the stdenv bootstrap could be structured like a cross from bootstrap tools to final environment. | 15:49:17 | |
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 | |
Then from there you could cross to another platform. | 15:49:53 | |
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 | |
Yeah, that's what I'm thinking | 15:51:36 | |
IIRC wasn’t there some talk about that for libc++ once libstdc++ gets split out of gcc? | 15:51:42 | |
Idk but probably | 15:52:01 | |
It would be nice to be able to view the stdenv as just tools and CC as the actual C toolchain | 15:52:42 | |
And you could override the unwinder, cxxlib, etc | 15:53:00 |