Nixpkgs Stdenv - Public Room Timeline

	Nixpkgs Stdenv	190 Members
		60 Servers

Load older messages

Sender	Message	Time
25 May 2025
emily	it uses `libcxx` for WASM, I guess? but does it use anything else from `pkgsCross`?	02:50:52
Tristan Ross	Yeah, idk	02:51:04
Tristan Ross	I think it needs wasilibc	02:52:01
Tristan Ross	Ok yeah, it needs a wasm toolchain. It looks like upstream uses the wasi-sdk.	02:54:37
Randy Eckenrode	How does `crossStdenv` handle cross-compiled dependencies? DXVK needs SPIRV and Vulkan headers and `windows.pthreads`.	13:39:07
Randy Eckenrode	Also, how does it handle `NIX_` vars? Does this even work with Darwin since Darwin needs an SDK?	13:44:42
Tristan Ross	In reply to @reckenrode:matrix.org Also, how does it handle `NIX_` vars? Does this even work with Darwin since Darwin needs an SDK? Suffix salt should work with the env vars. Idk about Darwin but it could be made to work.	14:28:05
Tristan Ross	In reply to @reckenrode:matrix.org How does `crossStdenv` handle cross-compiled dependencies? DXVK needs SPIRV and Vulkan headers and `windows.pthreads`. You'll have to override the stdenv for the dependencies.	14:28:23
Randy Eckenrode	In reply to @rosscomputerguy:matrix.org You'll have to override the stdenv for the dependencies. That doesn’t seem like an improvement.	14:29:31
Tristan Ross	In reply to @reckenrode:matrix.org That doesn’t seem like an improvement. I don't see really any other way of doing cross without either creating a new nixpkgs instance (what we already have) or only provide cross compilation stdenv's	14:30:30
Randy Eckenrode	DXVK uses a custom MinGW (with the Win32 thread model instead of the POSIX one). When you build `dxvk` on Darwin or Linux, it uses the cross-compiled 32- and 64-bit MinGW DLLs. https://github.com/NixOS/nixpkgs/blob/6fb6fd3ceff99de72d881f1a97773647c94e5a82/pkgs/by-name/dx/dxvk/package.nix#L28-L44 DXVK itself has dependencies: `spirv-headers` and `vulkan-headers`. Fortunately, those do not have transitive dependencies. (Arguably, DXVK has more dependencies, but I didn’t bother to de-vendor them.) 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 `stdenv`s and make sure they get the right dependencies themselves (thankfully easy for DXVK since they have none themselves).	15:08:53
Randy Eckenrode	`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
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.	15:15:22
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

Show newer messages

Back to Room ListRoom Version: 9