search

NixOS / nix

Nix, the purely functional package manager
https://nixos.org/
GNU Lesser General Public License v2.1
12.31k stars 1.49k forks source link

Windows MinGW support #1320

Open varosi opened 7 years ago

varosi commented 7 years ago

Tracking issue

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 commented 7 years ago

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 commented 7 years ago

Great! I mean in general to be officially supported.

vcunat commented 7 years ago

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 commented 7 years ago

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

varosi commented 7 years ago

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 commented 7 years ago

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

be5invis commented 7 years ago

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

be5invis commented 7 years ago

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

matthewbauer commented 6 years ago

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 commented 5 years ago

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

stale[bot] commented 3 years ago

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

aminya commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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[bot] commented 2 years ago

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

mausch commented 2 years ago

Unmarking stale, still relevant.

sskras commented 1 year ago

@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: https://github.com/NixOS/nix/blob/5985b8b5275605ddd5e92e2f0a7a9f494ac6e35d/config/config.guess#L152-L158

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 commented 6 months ago

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

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