Wouldn’t WSL mean that you would still have to cross compile everything? Otherwise you’d just be creating Linux executables.
I suppose you could invoke Visual C++ impurely in Nix and produce some stuff that way. But we’re pretty committed to free software in Nix/Nixpkgs/NixOS community. I definitely don’t think we should be supporting it. I would encourage everyone to give GCC/MinGW another try. I’ve found it to be pretty useful.
I guess the point is that they are orthogonal concerns. If you set allowUnfree, you can get unfree software; Visual C++ could be one of those. If you want to use the GCC/MinGW toolchain, that’s cool too.
But you said ‘impurely’, which makes me think I’m missing something - why would it be impure please?
It will depend if the MS C++ toolchain can be moved into a derivation output or not. Ideally the installer can be instructed to install into $out. The last time I checked, Windows executables weren’t supposed to write into the WSL filesystem.
Yeah I guess that can work. It looks like you should even be able to do execv(“hello.exe”, …). I wonder if there is a way to ask the kernel whether it supports that? If so, we can add “x86_64-windows” as an “extraPlatforms” in Nix:
After that we will just need to get bootstrap tools to work (it looks like there is no busybox available for windows?).
On Visual C++, I think you can just download the SDK directly from Microsoft:
Well, if it’s enough for you to also run the resulting packages inside WSL…
EDIT: this really depends on how good WSL can get in general. It would be really interesting if most SW could just drop developing Windows variants and stick mostly with POSIX (over the long term). Getting compatibility on par with Linux vs. *BSD differences might be quite a difficult task for the implementors, but Microsoft is surely big enough to afford that, and it might theoretically even pay off for them, helping to keep more people using Windows.
I would reserve “x86_64-windows” and “i686-windows” for the versions free of WSL and Cygwin.
We already have them as a cross-compilation target (pkgsCross.mingwW64 and pkgsCross.mingw32) and they could bootstrap in the future.
Use Windows symbolic links (nixbld users must have SeCreateSymbolicLinkPrivilege)
Use unprivileged hard links and store somewhere (in file streams?) information for GC about the “direction” of the links
Are there unprivileged directory hard links? These seem to be a substantial interesting problem for implementation…
When you are building against glibc, you could always patch glibc to treat desktop shortcut files (lnk) as symlinks — at least PocketBook did that for their Linux-based firmware with FAT32-formatted microSD cards, and it worked. I do not say it is a good idea; symlinks are probably better.
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 \\?\).
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).
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 https://metacpan.org/release/Win32-LongPath 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?
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)