Change:
, meson , ninja , windows <del> , src , version </del> <ins> , dxvkVersion </ins> , spirv-headers , vulkan-headers <del> , dxvkPatches </del> <ins> , SDL2 , glfw , pkgsBuildHost , sdl2Support ? true , glfwSupport ? false </ins> }: <ins> # SDL2 and GLFW support are mutually exclusive. assert !sdl2Support || !glfwSupport; </ins> let # DXVK 2.0+ no longer vendors certain dependencies. This derivation also needs to build on Darwin, # which does not currently support DXVK 2.0, so adapt conditionally for this situation. <del> isDxvk2 = lib.versionAtLeast version "2.0"; </del> <ins> isDxvk2 = lib.versionAtLeast (srcs.${dxvkVersion}.version) "2.0"; # DXVK has effectively the same build script regardless of platform. srcs = { "1.10" = rec { version = "1.10.3"; src = fetchFromGitHub { owner = "doitsujin"; repo = "dxvk"; rev = "v${version}"; hash = "sha256-T93ZylxzJGprrP+j6axZwl2d3hJowMCUOKNjIyNzkmE="; }; # These patches are required when using DXVK with Wine on Darwin. patches = lib.optionals stdenv.buildPlatform.isDarwin [ # Patch DXVK to work with MoltenVK even though it doesn’t support some required features. # Some games work poorly (particularly Unreal Engine 4 games), but others work pretty well. ./darwin-dxvk-compat.patch # Use synchronization primitives from the C++ standard library to avoid deadlocks on Darwin. # See: https://www.reddit.com/r/macgaming/comments/t8liua/comment/hzsuce9/ ./darwin-thread-primitives.patch ]; }; "2.1" = rec { version = "2.1"; src = fetchFromGitHub { owner = "doitsujin"; repo = "dxvk"; rev = "v${version}"; hash = "sha256-A4KR11brfQbR56dGt371MRwMN/H6HFAU8TlFC97/bRs="; fetchSubmodules = true; # Needed for the DirectX headers and libdisplay-info }; patches = [ ]; }; }; isWindows = stdenv.targetPlatform.uname.system == "Windows"; isCross = stdenv.hostPlatform != stdenv.targetPlatform; </ins> in stdenv.mkDerivation { pname = "dxvk"; <del> inherit src version; </del> <ins> inherit (srcs.${dxvkVersion}) version src patches; </ins> nativeBuildInputs = [ glslang meson ninja ]; <del> buildInputs = [ windows.pthreads ] ++ lib.optionals isDxvk2 [ spirv-headers vulkan-headers ]; </del> <ins> buildInputs = lib.optional isWindows [ windows.pthreads ] ++ lib.optionals isDxvk2 ( [ spirv-headers vulkan-headers ] ++ lib.optional (!isWindows && sdl2Support) SDL2 ++ lib.optional (!isWindows && glfwSupport) glfw ); </ins> <del> patches = dxvkPatches; </del> <ins> postPatch = lib.optionalString isDxvk2 '' substituteInPlace "subprojects/libdisplay-info/tool/gen-search-table.py"  --replace "/usr/bin/env python3" "${lib.getBin pkgsBuildHost.python3}/bin/python3" ''; </ins> <del> preConfigure = lib.optionalString isDxvk2 '' ln -s ${lib.getDev spirv-headers}/include include/spirv/include ln -s ${lib.getDev vulkan-headers}/include include/vulkan/include </del> <ins> # Build with the Vulkan SDK in nixpkgs. preConfigure = '' rm -rf include/spirv/include include/vulkan/include mkdir -p include/spirv/include include/vulkan/include </ins> ''; mesonFlags =

Discussion:
In future releases of dxvk the setup script won't be included anymore so this issue is just to notify so something can be figured out for how the nix package should handle it beforehand. (Hope such an issue is okay) See
CC
Thanks for the heads up. The DLLs are already available via a output, but this will break anyone’s set up that relies on . A short term solution would be to vendor the script. Longer term, it would be ideal if there were a way to declaratively create and manage a Wine prefix.
1 has been released with the script removed
I saw that. It can also build natively on Linux, which is interesting. I need to think about how I want to do things and maybe see what other distributions that package it are doing.
God speed
There is a nix-gaming repository that contains such derivation: It also handles vkd3d-proton:
One approach I’m considering is splitting dxvk into dxvk110 (for Darwin and hardware no longer supported by 2.0) and dxvk2x (or just dxvk_2, not sure). The plain DXVK derivation could continue to provide the script (most likely copied from before upstream removed it) while the versioned ones would be built for the native platform only (Linux and Windows). Well, I guess if it builds on Darwin, I can set the platform to then mark it broken on Darwin. I doubt DXVK 2.0 will work on Darwin any time soon. There are a number of extensions DXVK needs that aren’t implemented yet in MoltenVK, and since DXVK is always adding and using new ones, it’s a moving target.
I created to add the script and bump DXVK. It also exposes native builds on Linux.