lib.systems, windows: Add MinGW tuple

[RossSmyth]

Things done

MinGW and MSVCs' ABIs are not compatible. Generally a project only supports one or the other.

1. Allow CPU-mingw tuples to be parsed
2. Allow CPU-mingw tuples to be output
3. Add lib.platforms.mingw
4. Add lib.platforms.msvc
5. Edit the meta blocks in windows

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[RossSmyth]

There seems to be something funky going on with expecting some sort of array of tuples, and that array has now changed. Should exclusively be more platforms now

[Ericson2314]

@RossSmyth I think we did this before, but there was some problems with autoconf stuff barging on windows-gnu. I sent some emails about this but it was messy. Adam Joseph, who has since quit Nixpkgs stuff, had differing opinions too.

[Ericson2314]

https://lists.gnu.org/archive/html/config-patches/2023-06/threads.html see this, and messages over the following two months. (wish there was way to succinctly view multi-month threads.)

[alyssais]

These are supposed to match the doubles Nix would use for builtins.currentSystem when built for that platform, so this is only correct if that would report mingw on mingw.

But that raises another problem I hadn't noticed before: @Ericson2314, it doesn't look like any attempt to preserve compatibility was made when the double generation logic was ported to Meson. For example, power64-linux will now be detected as ppc64-linux, and then not recognised by Nixpkgs. That seems not good! Now a Nix built on that platform won't be able to do anything useful with Nixpkgs, so I think that probably needs to be addressed in Nix to restore the old behaviour, which shouldn't have been changed and shouldn't change again in future…

[RossSmyth]

Since we don't support MinGW, or windows at all yet, that seems fine.

[Ericson2314]

@alyssais See NixOS/nix#13520, we noticed more recently, fixed it (in two PRs), and did a bunch of backports.

[Ericson2314]

Since we don't support MinGW, or windows at all yet, that seems fine.

Note that the main, core use of the doubles is "what derivations are allowed to run there". I don't think there are MSVC-only or MinGW-only builders, so xxx-windows is probably fine?

[RossSmyth]

Hmmm

We need some way to express "this is only compatible with the MinGW ABI" because right now every package that uses platforms.windows is currently asserting that it is compatible with the MSVC ABI. It is basically the difference between musl and GLibc on Linux.

[alyssais]

Which we can encode fine with our existing "patterns" system for platforms, without needing separate glibc and musl doubles.

[alyssais]

For example, bash is already marked incompatible specifically with mingw

[RossSmyth]

The biggest difference is that musl and glibc are generally API-compatible. While MinGW and MSVC generally are not.

[Ericson2314]

I don't think the forth component needs to distinguish between ABI-compatible options.

For example (sort of), back int he day there was Debian GNU/kfreebsd, using glibc. (Not our like our BSD support using matching BSD kernels and libcs.) The config they used is i386-kfreebsd-gnu, and I don't think that was ABI compatible with regular FreeBSD very much (even if they both use the Itanium C++ ABI).

[alyssais]

The biggest difference is that musl and glibc are generally API-compatible. While MinGW and MSVC generally are not.

Yep, that's why we don't need to use the platform patterns much so far. But this is the problem they solve, and we can use them more as required. That's what they're for.

[RossSmyth]

I see. I guess the main brother I have is that if you do systemToAttrs to the current platform.windows, none of them are mingw.

[alyssais]

Yep, just like none of them are musl. In practice this matters extremely little. We have to have a default for a platform, but it's not difficult at all to use a different one.

[RossSmyth]

Okie dokie