Dropping Cygwin support

Is anyone still using Nix on Cygwin?

I am working on changes that would likely break any remaining support for Cygwin, and there is no way to build or test Nix with Cygwin. It is not in the list of supported platforms.

I am trying to add support for native Windows (using mingw-w64).

3 Likes

I don’t think it is currently used by anyone, so some breakage might be okay. However, we definitely want to make it easy for someone to readd support in the future. In theory it should be much easier to support than mingw-w64 & require less patching, but it’s not used very much any more with WSL available.

1 Like

In our company we use every day nix on cygwin since years. Some months ago I also reported a bug in nix 2 that got fixed, and since then we use the latest nix just fine.
Of course we use it with non-public nix expressions that involve Microsoft compilers and so on.
Please don’t break nix on cygwin.

On the other hand, we welcome a native nix for Windows too.

5 Likes

That’s pretty impressive. Do you have any articles or documentation about it?

I’m specifically interested on how to build, install and run Nix on Cygwin. I would also love to know how you’ve integrated it with VS and how well it works compared to other build and packaging tools or compared to Nix on WSL.

Sidenote: I feel like removing support for something is basically guaranteed to decrease portability?
I.e. you WILL end up with something that doesn’t port eventually.

2 Likes

As there are some Windows users, what do you think about adding support the drive letter to the Nix Parser when it parses paths?
I filed an issue 6 months ago https://github.com/NixOS/nix/issues/2603 and get no reaction, concluding that noone cares about Windows or Cygwin.

Ah no I don’t have any public example. Our nix files are pretty simple though; we basically have a replication of vsvars in bash syntax, and we try to support multiple compiler versions, SDK versions, ucrt, etc. To have some reproducible results on fixed nix hashes, at least.

But we don’t build nixpkgs with those recipes; only the libs/programs we use for our development. Nothing special - some open source mathematics and i/o libraries. We even don’t use nix-shell for the development environments but we have recipes for scripts that behave like nix-shell.

1 Like

By now cygwin nix has been enough so I never cared about the non-unix paths. But some colleagues have a desire for a cygwin-less solution because the programs run faster in either WSL or native windows, and then this may have a role.

It’d be nice that a cygwin nix could evaluate the same kind of recipes as a mingw nix, and the paths worked just fine, not requiring different recipes. The same way one can use git for mingw or git for cygwin, in a windows machine.

EDIT:
1st time I use this discourse, and created an account only to answer this topic. It says I reached the limit of Replies in this topic and that I should edit my previous replies instead. The last nix we use 2.0.x doesn’t need libeditline. So maybe someone broke the normal cygwin build by adding that.

1 Like

Sharing the same store between Cywin, WSL (and a potential native Nix) sounds like a great idea. I might give it a try, but I can’t think of a maintainable way to get either symlinks or GC to work correctly.

How do you build Nix on Cygwin, without Nix? I was not able to get the latest tarball to build: ./configure doesn’t find libeditline and doesn’t recognise libreadline

I have native Nix fork at https://github.com/volth/nixpkgs-windows https://github.com/volth/nix-windows (with MSVC and Perl as stdenv.shell because there is no bash working properly with Windows path names, all bashes require some sort of FHS emulation (moreover there no perl nor coreutils working properly with Windows long paths, build process of some native program use long paths which stdenv has to me able to cp -r and rm -rf at least). Perl + some 3rd party modules Win32::LongPath + patches not accepted by upstream was the closest shell to support all kinds of paths. Perhaps I had to use Powershell.

It builds Perl, Python, LLVM, Chromium, Win64Dbg, …
Mingw binary packages can be unpacked to c:\nix\store as-is, without recompilation or patchelf'ing, there is an updater script for them.
My goal was mainly to build Chromium with native Windows font rendering (free of freetype ugliness), so the development is stuck after the goal was achieved.

6 Likes

@volth That is amazing work! I would love to use it and complete it to make it easier to merge upstream (if there’s enough support for it). I see there’s a few bugbug/??? comments and no symlinks. I had been considering a busybox-w32 + clang-cl stdenv.

I was able to build on Cygwin, using -lreadline -DREADLINE. I’m working on getting some of the tests to work. I’ll try to figure out what other dependencies I needed so I can write some docs.

The big refactoring needed in upstream is replacing Nix’s class Path with something character-size (char or wchar_t) and delimiter (/ or \) agnostic, for example boost::filesystem::path.
It is what is difficult to solve by #ifdef _WIN32, because Path is everywhere.
That issue above was supposed to be the first step :slight_smile:

1 Like

Another cluster of issues: Nix build process (long prefixes in c:\nix\store\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, symlinks everywhere, long environement variables, …) reveals many bugs in Windows utilities, not only hacky ports like msys bash, but also in native ones, such as 7zip https://sourceforge.net/p/sevenzip/bugs/2174/ and ninja https://github.com/ninja-build/ninja/issues/1514 and Win32::LongPath https://github.com/rdboisvert/Win32-LongPath/issues/8 https://github.com/rdboisvert/Win32-LongPath/issues/10
They are still unfixed in the upstreams.

Rewriting something like https://github.com/NixOS/nixpkgs/blob/dd422da4b868c3fce96ee55a7730a81ca6cec9c8/pkgs/stdenv/generic/setup.sh to busybox-w32 shell would result in forking of busybox :slight_smile:

2 Likes