Nix on Windows?

Development
36

Actually, there is no choice on how to implement symlinks.
There are symlinks in git repos (for example LLVM’s) and source tarballs, so the only option is to follow Git’s and archivers choice.

A funnier problem is the prefixes added by Nix (not only nix store paths like C:\nix\store\nj8672hwq8r54b9f1njs1i1dwajipncd-material-sprited-animation-view-ios-8af9ada\, but also build roots like C:\Users\User\AppData\Local\Temp\nix-build-chromium-73.0.3660.2.drv-0\chromium-73.0.3660.2-src\) often result in full paths longer than 254 chars. Supporting longer paths requires special effort not only from Nix itself but also from all the programs involved into build process (long paths passed to API must be absolute, must contain no \..\ and be prefixed with magic prefix \\?\).
That means:

  1. there is no reliable ready-made to do cp -r. Windows’ own xcopy does not work with long paths. robocopy does, but it has other bugs (it cannot copy from readonly nix store, so cannot be used on unpackPhase after fetchzip/fetchgit).
  2. stdenv.shell (the script language used in buildPhase, etc) should support long paths. Currently I am using Perl which does not support it out of the box, so I have to use Win32-LongPath-2.2 - Windows file functions that use very long paths and Unicode. - metacpan.org and thus resulting code is not portable. Perl’s own function open, glob, … do not support long paths and cannot be used on Windows reliable, Win32::LongPath’s functions are Windows-only. So I am in doubt what could be a portable stdenv.shell then… nodejs? miniruby?
  3. Third party build tools should be fixed. So far only cmake correctly handled long paths (I did not investigated how, just saw a cmake warning about “path being longer than 255 bytes” but the build succeeded), ninja has the problem (https://github.com/ninja-build/ninja/issues/1514)
4 Likes