In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Done with the help of https://github.com/Mindavi/nixpkgs-mark-broken
Tool is still WIP but this is one of the first results.
I manually audited the results and removed some results that were not valid.
Note that some of these packages maybe should have more constrained platforms set
instead of broken set, but I think not being perfectly correct is better than
just keep trying to build all these things and never succeeding.
Some observations:
- Some darwin builds require XCode tools
- aarch64-linux builds sometimes suffer from using gcc9
- gcc9 is getting older and misses some new libraries/features
- Sometimes tools try to do system detection or expect some explicit settings for
platforms that are not x86_64-linux
I am not sure if we still need the old packages, nothing explicitly
depends on polyml56 or polyml57 according to a grep, not sure if
external packages might (hol and isabelle depend on polyml, the latest
version).
New libffi doesn't have FFI_SYSV for x86/64 unix, this pulls in the
commit for the upstream version which fixes it, and ports that patch to
the 5.7 version. The 5.6 version is unchanged.
For ZHF: #80379
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/polyml/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/ac6iwd3ixncb9cqjg59fbj2nzcfmsqgn-polyml-5.7.1/bin/poly --help` got 0 exit code
- ran `/nix/store/ac6iwd3ixncb9cqjg59fbj2nzcfmsqgn-polyml-5.7.1/bin/poly -v` and found version 5.7.1
- ran `/nix/store/ac6iwd3ixncb9cqjg59fbj2nzcfmsqgn-polyml-5.7.1/bin/poly --help` and found version 5.7.1
- ran `/nix/store/ac6iwd3ixncb9cqjg59fbj2nzcfmsqgn-polyml-5.7.1/bin/polyc --help` got 0 exit code
- ran `/nix/store/ac6iwd3ixncb9cqjg59fbj2nzcfmsqgn-polyml-5.7.1/bin/polyc --help` and found version 5.7.1
- found 5.7.1 with grep in /nix/store/ac6iwd3ixncb9cqjg59fbj2nzcfmsqgn-polyml-5.7.1
- directory tree listing: https://gist.github.com/e23988ea219cf9deddb7b7c0578cfd89
