Windows MinGW support

[varosi]

Tracking issue

• Allow getting in a MinGW dev shell #9519 Get in a development environment
• Build a minimized Nix with MinGW #8901

Original description

Currently Stack is using MinGW32/MinGW64 under Windows to cope with C/C++/Fortran dependencies. Stack + Nix is a great tandem that could be turned into very easy to deploy system on most major operating systems. That way Haskell will become even more popular language. Currently Nix support Linux and Mac OS only.
What you think over the idea to use MinGW tooling in combination with Nix for building C/C++ dependencies under Windows?

[vcunat]

It's probably not what you want, but I used to use nix for cross-compilation Linux->MinGW – to do CI on Windows SW without actually needing any Windows. Some packages needed fixing, but most problems could be resolved by finding patches on the internet (pushed those to the official nixpkgs repo).

I heard of standard nix used on i686-cygwin, not too long ago, but it's certainly not among the "top-tier" platforms.

[varosi]

Great! I mean in general to be officially supported.

[vcunat]

IMHO "official support" is mainly about getting enough people interested so they manage to keep it working well. Some basic cross-compiled binaries are produced by the build farm already: http://hydra.nixos.org/jobset/nixpkgs/cross-trunk#tabs-jobs

[domenkozar]

https://github.com/DavidEGrayson/nixcrpkgs/tree/master/mingw-w64

[varosi]

So it is possible (theoretically) Stack to run under Windows (with MinGW) and do use Nix package system for building dependencies under Windows for Windows?

[domenkozar]

@varosi with WSL, I think it should be possible. This is something I'm interested in as well.

[be5invis]

@midipix may be another option.
But... it may be better if we can go NATIVE, i.e., no dependency, no framework.

[be5invis]

@domenkozar I do not think that using WSL is "under Windows".

[matthewbauer]

Has anyone ever been able to build Nix itself through MinGW? I would be interested in seeing if anything works. Multi-user stuff is pretty reliant on POSIX things but the basic Nix commands are pretty straightforward C++. I'm sure the filesystem would struggle though.

[7c6f434c]

I think MinGW/MSYS2 bash per se can be considered native.

[stale]

I marked this as stale due to inactivity. → More info

[aminya]

There is this repository called Nix-windows. Not sure in what state it is.
https://github.com/nix-windows/nix

I have also been interested in using Nix for some open-source projects. However, because Nix doesn't support Windows, I am not sure if this is an inclusive decision, as this would ignore a huge portion of the developers.
The only solution I can think of is to offer a native build system as well as a Nix-based build system.

[kvtb]

There is this repository called Nix-windows. Not sure in what state it is.
https://github.com/nix-windows/nix

I have also been interested in using Nix for some open-source projects. However, because Nix doesn't support Windows, I am not sure if this is an inclusive decision, as this would ignore a huge portion of the developers.
The only solution I can think of is to offer a native build system as well as a Nix-based build system.

Nix works on WSL and Cygwin just out of the box.
Port to MSYS is pretty straightforward.

[aminya]

Nix works on WSL and Cygwin just out of the box.
Port to MSYS is pretty straightforward.

Thanks. That's better than nothing, but I wish there was native Windows support.

[kvtb]

Nix works on WSL and Cygwin just out of the box.
Port to MSYS is pretty straightforward.

Thanks. That's better than nothing, but I wish there was native Windows support.

The main discussion/changelog on native seems to be at https://discourse.nixos.org/t/nix-on-windows/1113

[kvtb]

I really wonder why nixpkgs did not appear first for native Windows. The idea of "portable apps" ("portable" here means the ability to copy app into any directory or cdrom - the read only media! - and run from there) was very popular in Windows. It is familiar to millions of people who grew up with Windows. Even considering that most applications did not need to be compiled, just because they were closed source, from the routine task of downloading_torrent -> patching -> putting_into_apps_own_directory it was natural to develop something similar to nixpkgs

[corngood]

Nix works on WSL and Cygwin just out of the box. Port to MSYS is pretty straightforward.

@kvtb Do you have any recent info on getting nix working on cygwin? I had issues with boost coroutines, and I had to modify the cygwin runtime to get it to work:

https://cygwin.com/pipermail/cygwin-developers/2020-September/011970.html

I've got to the point where I can bootstrap nix on cygwin, but it involved changes to cygwin, nix, and nixpkgs.

[stale]

I marked this as stale due to inactivity. → More info

[mausch]

Unmarking stale, still relevant.

[sskras]

@be5invis commented on Apr 15, 2017:

@midipix may be another option. But... it may be better if we can go NATIVE, i.e., no dependency, no framework.

Well, by native do you mean linking to MSVC runtime (CRT) lib or calling WinAPI?

In any case, the calls go through at least one or two API layers to reach NTAPI (Native API, the syscalls wrapper). Both these cases also require having a bunch of additional header files to be present. So it (technically) would still be a framework.

And NTAPI is exactly what @midipix uses too to implement *nix style libc functions (the alternative layer).

Only that it follows the MUSL semantics instead of the GLIBC ones. But nix already supports MUSL, I guess:

nix/config/config.guess

Lines 152 to 158 in 5985b8b

	#else
	#include <stdarg.h>
	/* First heuristic to detect musl libc. */
	#ifdef __DEFINED_va_list
	LIBC=musl
	#endif
	#endif

With regard to having no dependency, every Midipix-based app (and I believe everty lib) can be linked statically.
Quoting what is midipix, and how is it different? | easy distribution:

midipix supports both static and dynamic linking; there are no assumptions about the directory structure on the end-user machine, and unlike SUA/Interix, no special installation of a Windows component is required.

Midipix applications running on the same system are completely independent of one another; as opposed to cygwin there is no arbitrary inherited state between two unrelated applications, and the crashing or misbehavior of one application can in no direct way affect another.

The one intentional exception to the rule is that of POSIX sessions, where you would want such inheritance and integration to take place.

For instance, you would want an application created via fork(), execve(), or posix_spawn() to inherit its file descriptors (and in the case of fork() also address space) from its parent, and would likewise want termination of a child application to cause a SIGCHLD signal to be sent to the parent.

So, no binary dependency here either.

I think Midipix is a very cool way to go. Only that it's still pre-alpha.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-on-windows/1113/105