The Minimalist Gnu for Windows distribution comes with support for
the traditional msvcrt libc, as well as ucrt64 libc. The latter
being the newer universal compiler runtime. We follow the msys2
environment naming convention[1]:
| name | toolchain | arch | libc | libc++ |
|------------|-----------|---------|--------|-----------|
| mingw32 | gcc | i686 | msvcrt | libstdc++ |
| mingw64 | gcc | x86_64 | msvcrt | libstdc++ |
| ucrt64 | gcc | x86_64 | ucrt | libstdc++ |
| clang32 | llvm | i686 | ucrt | libc++ |
| clang64 | llvm | x86_64 | ucrt | libc++ |
| clangarm64 | llvm | aarch64 | ucrt | libc++ |
For now nixpkgs only supports the first three with this commit.
--
[1]: https://www.msys2.org/docs/environments/
Right now converting `makeScope` to `makeScopeWithSplicing` is not
transparent to users and requires adding a warning for `overrideScope'`
in the set itself.
Warning and `overrideScope'` were added in 2018 b9dce11712 and there should be no users left after 5 years.
Deeply-curried functions are pretty error-prone in untyped languages
like Nix. This is a particularly bad case because
`top-level/splice.nix` *also* declares a makeScopeWithSplicing, but
it takes *two fewer arguments*.
Let's add a version that uses attrset-passing form, to provide some
minimal level of sanity-checking.
This also provides defaults for keep and extra (these are often
unneeded by the user).
These statements are taken from the `lib/test/release.nix` tests,
which previously also worked on darwin.
Unblocks https://github.com/NixOS/nix/pull/8569 when backported
This reverts commit c59c6b1c57.
This was a bit too ambitious, because no warnings were previously
triggered when `string` was nested e.g. `attrsOf string`, `nullOr
string`, etc.
Support for nested type deprecation warnings was introduced in
4b54aedee5, but had to be reverted in
a36e6760e9 because it caused infinite
recursion for some users, and I couldn't remember that it was reverted.
The type has given a warning on use since [4 years ago](03392cd336b128a1639c648baf0f6c1a1271e0d2), I think it's safe to move the deprecation to the next stage: An error instead of a warning.
Before this commit, getExe assumes that if `meta.mainProgram` is unset,
it has a main program that's named after the package name.
While this is probable, it leads to a bad error when the assumption does
not hold. If the user called `getExe` themselves, they might narrow down
the location of the assumption quite easily, but if that's not the case,
they'll have to go down the rabbit hole to figure out what went wrong.
For example, a NixOS module may use `lib.getExe` on a package-typed option
which is then used in the system configuration. This then typically leads
to a failure *after* deployment, which is bad, and it's quite likely that
the user will debug the package output contents before digging through the
NixOS module, which is bad.
Furthermore the `getExe` call is rather inconspicuous as it does not
contain something like "/bin/foo", which is bad.
Also modules can be hard to read for a newbie, which is bad.
All of this can be avoided by requiring `meta.mainProgram`.
Many packages already have the attribute, and I would expect 80% of
`getExe` usages to be covered by 20% of packages, because plenty of
packages aren't used with `getExe` anyway.
Finally we could make an effort to set `mainProgram` semi-automatically
using `nix-index`.
Deeply-curried functions are pretty error-prone in untyped languages
like Nix. This is a particularly bad case because
`top-level/splice.nix` *also* declares a makeScopeWithSplicing, but
it takes *two fewer arguments*.
Let's switch to attrset-passing form, to provide some minimal level
of sanity-checking.
mkOption does not require a `type` argument and does not set the
resulting attribute if it is not given. Consequently, we need to be
prepared to merge options that have no type information.
